HEWLETT-PACKARD 

JOURNAL 



June 1996 




Copr. 1949-1998 Hewlett-Packard Co. 



WAffi HEWLETT 
mL'fLm Packard 



In M e m o r i a m 

Dave Packard 
1912-1996 




Dave Packard's idea for the HP Journal originated with a publication called the Experimenter. 
published by ihe General Radio Company, "I remember drooling over the Experimenter when 
I was in high school," Dave told Karen Lewis, HP's anhivisi and historian. Featuring an article 
entitled U A New Amplifier fi» Milli-Microsecond Pulses/ 1 the HP Journal made its debut in 
September, L94& 

Packard l»elie\"ed the Journal's role was lo describe The technology used in the development 
of important HP products, and that it should be a vehicle for sharing such information with 
ihe larger engineering community. He also felt the Journal should recognize the contributions 
of individual HP engineers to the company and the electronics industry, Forty-seven years 
later, on the occasion of Daw Packard's passing, we at the Journal are still dedicated to those 
goals. 
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What's Ahead 

The first six articles in the August issue will describe HP's current software engineering practices. Five of the 
articles are from HP's Corporate Engineering software initiative group and one article is from HP's Software 
Engineering Systems Division. There will also be five articles from HP h s 1995 Electronics Packaging and Man- 
ufacturing Conference, 
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In this Issue 

The most unpredictable and time-consummg part of developing a complex digital sys- 
tem is the system integration phase. During system integration, the various hardware 
and software subsystems finally come together for the first time. Although the inter- 
dependences between the various subsystems have been simulated, emulated, and 
unit tested before system integration, there are always surprises. These surprises, or 
"hard problems," (page 6) dramatically affect the time-to-markei goafs for the product 

To find the root causes for these hard problems, engineers need to see what is going 
on in several subsystems (e.g., operating system, memory, I/O, etc.) at once. The article 
on page 15 describes a tool that assists engineers in the search for root causes, The 
tool is called the HP 16505A prototype analyzer The HP 16505A is an XI 1/Motif application that runs on an HP 
9000 Model 712 workstation connected to an HP 16500 logic analyzer This configuration provides a graphical 
user interface (GUI) that enables users to create a measurement setup using icons that represent HP 16500 
hardware modules and HP 16505A software modules. The software modules display or list the time-correlated 
data from the instruments in a variety of formats. To deal with the variety of data types from the instruments 
and the data uniformity requirements of the analysis and display modules, data is normalized immediately 
after acquisition and made available to all the output modules in a standard format (page 30). The selection of 
the encapsulated measurement server architecture of the HP 16505 A (page 22) was based on feedback from 
an analysis of customer needs and requirements. 

Allowing targeted users to participate in the design of a product is the best way to focus product goals and 
hopefully produce a successful product The HP 38G graphing calculator (page 45) is a calculator designed 
for precalculus students and their teachers. In addition to the typical HP design team, an Educational Advisory 
Committee consisting of high school, community college, and university teachers was formed to help in de- 
signing this product The HP 38G is huilt on the same software platform as the HP 48G graphing calculator, so 
ft has many of the capabilities of the HP 48G but with a simpler user interface and a capability called aplets. 
An aplet (page 59) is a small application that focuses on a particular problem. Thus, teachers can keep students 
focused on a particular scientific or mathematical concept (e.g., polygons) by creating and downloading a set 
of aplets for students to work on. 

HP OmniBook computer users are used to the idea of having a small mobile computer with some of the same 
capabilities and applications as their desktop machines However, with features such as color displays, larger 
hard drives, and faster processors appearing in the HP OmniBook family of notebook computers, the expecta- 
tion is to have a full-featured notebook computer with the same capabilities as desktop computers (of course 
not with the same performance as the high-performance desktop models), The article on page 38 describes the 
HP OmniBook 5000 r which is a full-featured notebook computer based on the Pentium processor. This product 
is designed to satisfy the demand for a notebook computer with complete desktop computer capabilities. 

Today's mobile paging systems allow people to keep in 24-hour contact. One group of people who especially 
need this kind of service are physicians caring for critically ill patients. They need access to all the clinical 
patient information (graphical and textual) no matter where they are. The HP PafmVue system (page 64) fulfills 
this need by allowing the transmission of clinical patient information via conventional alphanumeric paging 
systems. The system integrates computer networks, palmtop computers, paging systems, and physicians who 
use HP monitoring systems and cardiographs to deliver high-quality patient data to mobile physicians. 

HP divisions are always trying to find tools and processes to increase productivity and improve the quality of 
products, The last two articles in this issue describe efforts aimed at these quality and productivity goals The 
first article (page 70) describes a tool that helps system administrators deal with installing and maintaining 
applications in an environment where there are hundreds of workstations and servers. The second article 
(page 76) describes software translators that facilitate the development of programs consisting of high-level 
(Manguage modules and low-level assembly-language modules. Such dual-language programs are common 
when old software modules are reused, 

C.L Leath 
Managing Editor 

Pentium is a U.S. tradem^* nf Intel Corporation 

OSF. Motif, and Open Software foundation are trademark of the Open Software foundation in the U S A and other 1 1 
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Reducing Time to Insight in Digital 
System Integration 

Digital design teams are facing exponentially growing complexities and 
need processes and tools that reduce the time needed to gain insight into 
difficult system integration problems. This article describes modern digital 
systems in terms of the problems they create in the system integration 
phase. The debug cycle is described with special emphasis on the "insight 
loop," the most time-consuming phase of system integration. A case study 
from an HP workstation design effort is used to illustrate the principles. 
A new digital analysis tool, the HP 16505A prototype analyzer, is introduced 
as a means of solving these vexing problems more quickly by reducing 
time to insight. 

by Patrick J. Byrne 



The digital revolution is upon us in every form. Computer 
I lerfonuance doubles every 18 months. Networks of high- 
performance servers are replacing main frames at a dizzying 
pace . P ersonal comnum i cat i on sy st e HIS are pervas i v e , f i < m i 
remote sales tools to medical information systems to net- 
worker.! workgroup tools. 

What is behind this revolution? The answer is hardworking 
teams of engineers focused relentlessly on reducing lime to 
market with the Latest silicon and embedded systems. These 
teams of engineers are taking the latest silicon Technology in 
ASICs (application-specific integrated circuits) and memory, 
exploiting them while adding value in the form of special 
appli* ;n ion-focused architectures and implementations, and 
bringing the end products to market at the right lime, price, 
and performance. These efforts are often made up of highly 
integrated subteams of four to eight engineers — hardware 
development: specialists with expertise in ASIC design, 
printed circuit board system design, hardware architectural 
trade-offs, and the latest CAE (computer-aided engineering) 
tool methodologies. These teams specialize in designing 
high-performance, efficient . embedded software systems 
using the latest software design tools and languages. It is not 
unusual for design teams to use C-+ and to have a carefully 
crafted multilayer software system with de facto APIs (ap- 
plication programming interfaces) between layers. These 
abstractions are used to manage the growing complexities 
of real-time embedded systems. These teams have to keep 
the customer in clear view as they make complex trade-offs 
between software and hardware implementation, between 
time to market and feature sets, between material cost 
■ kence rustomer juice) and component soiimug risks. 

Concurrent Design and the Integration Phase 

Pigs, 1 and 2 illustrate the nature of the modern digital design 
process. Fig. 1 shows how the many competencies are 
brought together by the design team into the end product. 
The modem digital design process is highly concurrent. To 



make progress, each engineer makes assumptions about the 
other engineers' work. Sometimes these assumptions are 
we 11 -documented, but often they are not because of the 
relentless schedule pressures. The risk accumulates through- 
out the design process because the loots used by different 
members of the design team do noi explicitly articulate the 
interdepend encies between subsystems. These design inter- 
dependencies are often found in the integration phase, when 
the whole design comes together for the First time* This is 
the well-known finger-pointing phase. * It's a hardware prob- 
lem." says the software engineer. "It s a software problem." 
says the hardware engineer. The team member then sort 
mut the problems from their respective points of view, en- 
gaging in the iterative and unstructured debug process. 

Pig, 2 shows this development process in terms of cycle 
times. Twenty lo thirty percent of (he entire development 
process lime is used in I his unstructured integration phase. 
This phase of the design process is unstructured because 
there are so few well-designed tools and processes for engi- 
neering teams to use to work through the key integration 
tasks. In the integration phase, hind ware meets hardware in 
the form of ASICs interacting with the circuit board. Inter- 
hardware design and modeling flaws are found here. Hard- 
ware meets software in the form of driver code running 
ASIC subsystems. There are also problems from application 
programs causing soft war* ■ integration problems, Application 
code provides an incredibly rich and complex stimulation 
system lo the hardware. 

1 {aid ware and software modeling tools (simulators, compil- 
ers, logic synthesis, etc.) falter in their ability lo nmdel all 
these complex combinations, sequences, and data and code 
interdependencies. Fig. 3 Shows the simulation execution 
speed of a typical 4tt.Mll/ system. Most digital circuit simu- 
lators execute at 10 to AO cycles per second, leading to tola! 
system simulation rimes of days and sometimes weeks. This 
is loo long for designers who are used lo the iterative design 
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Fig* 1. I nxitat system design process. 



and debug process. This shows that simulators are just too 

slow in expose real-world problems within the mental time 
constants designers need. 

Hard Problems in the Real World 
This licit and complex environment is fche real-world envi- 
ronment indicated in Big* 2. The modeled world in Fig, 2 is 
where designers work in isolation to predict real- world 
behavior. Bm it is viiy hard to precfid even corner case to 
which the acuta) applicatjona will lake complex combina- 
tions "i hardware and software. The real-world environment 
is the domain oftiiie "hard problems," also called the "inter- 
esting cases" hy some engineers. The software icam has 



done their best to model the hardware, The> have read the 
hardware documentation and writ ten their driver and appli- 
cation code consistent with these models. The hardware 
engineers have dour their hest to model tin- software. < H'len. 
hard wan- engineers will standardize hardware interfaces 
specifically lo avoid im mode led software behavior. However, 
« ii'-n Ihe (eani puts the system together, they find nnmodeled 
or tindermodeled rases— the interesting cases. They find 
that their documentation doesn't cover .some Sequence of 

behavior by which the application code s the ASIC into a 

state machine or switching condition that causes a glitch 

that delays response, causing the software to lime out at ihe 
fourth layer of the protocol. It is very common to have the 
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problems in the real world be separated, symptom from root 
cause, both temporally and spatially. For example, an ASIC 
on a peripheral bus has a stare machine sequence that causes 
an error condition, but the errored packet is not sent back fcd 
the CPI ' until it fits into the priority stack. Or even more 
simply, the bad data is written to memory a long time before 
it is read and found to be faulty. The problem is detected 
later in time and at a different point in the system from 
where and when it was caused. Multiple bus architectures, 
such as Peripheral Component Interconnect (PCI), using 
intelligent queueing techniques, make these kinds of laten- 
cies commonplace, 

Another common real- world problem is the infrequent prob- 
lem that only happens at odd. nonrepeatable times because 
complex hardware and software systems have deep memory 
capacities and latencies in registers and state machines in 
addition to complex logical extent, The hard problems are 
those that the system stimulates through complex interac- 
tions between big application systems and deeply sequenced 
complex hardware systems. Odd pairings of hardware and 
software states cause infrequent behavior Every engineer 
knows the problem of solving an infrequent system crash. 

Another common real-world problem is the hidden depen- 
dency. This is caused by underspe rifted subsystems working 
together at blinding speeds. It is just hot possible to specify 
every hardware or software component's ultimate use, Envi- 
ronmental conditions like temperature or application loading 
stress the system to expose these hidden dependencies. The 
case study described later in this article will show how sim- 
ple and "perfectly specified" TTL parts can be the root cause 
of a very nasty operating system crash. This is typical of the 
hard problems. 



Complexity: Growing Exponentially 

The root causes of these kinds of vexing problems are hard 
to anticipate and hard to find. They delay projects and defy 
schedule prediction for managers. The reason they are su 
common is the exponentially growing complexity of today's 
systems. Silicon allows systems with 50,000 to 100,000 gates 
to be combined with 32-bit (PI architectures with out -of* 
order execution and large on-chip caches, controlled by 
3M-to-10M-byte embedded software systems. These soft- 
ware systems are designed carefully with multiple layers of 
functionality to promote reuse and maintainability These 
software layers, combined with poor code execution visihihn 
because of caches and queues, can create indirection and 
poor observability during the integral ion phase, 

Fig. 4 illustrates the exponentially growing complexities of 
todays subsystems. ASIC integration allows entire subsys- 
tems to be placed beyond the eyes of probes. Modern CPUs 
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have 10 million transistors and multiple execution units. 
Embedded systems grow as well. All these technologies are 
brought to bear at varying levels of risk to be competitive 
today. Teams must master not only the individual technolo- 
gies but their inevitable integration. The complexity simply 
overwhelms. It is very difficult for engineering teams to pre- 

all the inteni' etween such complex sub- 

systems. Few engineer- f the 

details oi uiolugy to predict the conditions that will 

cause a failure during integration. Engineers ha\ e to know 
their design tools: what they do right and what tin y do 
wrong. They have to know the system functionality and how 
rl reflects down to the details of their design and the design 
of the next engineer. They have to know how to unravel 
odd sequence of events that causes the infrequent system 
failures. Most hard problems must be solved by teams of 
engineers because the complexities of the interactions cross 
engineering disciplines. 

Iterative Debug Loop 

The process used by engineers to solve these complex inte- 
graiion problems that have eluded their design tools is illus- 
I rated in Fig. 5, The engineers start in the upper right corner, 
identifying the problem first by clarifying the symptoms 

The next step in the process, isolating problems correctly, is 
often tricky, Rumors and "old problems — old solutions" 
confuse. It is very common to jump to conclusions based on 
symptoms because the engineer once saw a problem like 
this before and solved it in a certain way. The correct ap- 
proach is to perform what doctors call a differential diagno- 
sis^-describing In detail and with accuracy what has changed 

from the correi tly working condition that could can s< 8 
problem, thereby isolating the unique operational sequence. 
This takes discipline and careful anah sis 

The next phase is to cHsooveJ (fee hardware or software de- 
pendencies that consistently describe the unique configura- 
tions and sequences to describe the problem correctty, 
Sometimes a binary search technique is used: code is sliced 
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Fig. 5, Iterative debug loop, showing the insight loop. 



apart and patched back together to stimulate the hardware 
lo the unique and small code segment that reliably repeats 
the problem* Experience and intuition are very important 
here because hard problems seem to have classic root causes 
but a variety * if syHtpti wis, discovered over and over by each 
generailon of engineers, Yet the process must be data-driven 
so that the team is not led to false conclusions. 

ft is oftei thai only one w twemy engineers can 

correctly isolate the dependencies and sequences, i 
because few people are chartered with the task and have the 
experience to understand the total picture of how a system 
works in enough pervasive detail to lead structured detective 
work. The next phase in die debug cycle is finding the true 
root cause. Infrequent problems, large unobservable ASIC 
systems, complex software - aid time pressures 

make this task difficult. But it is very important to find the 
true root cause or a simple fix will unravel when some hid- 
den dependency is invoked, A new solution causes another 
problem. A small change in temperature, voltage, or applica- 
tion loading will cause the fix to stress to the breaking point 
Margins will be broken. This is the ^insight loop*: the struc- 

I detective work needed to synthesize the irue tool 
cause from confusing and overwhelming data sets caused by 
vast complexities. The ability to reach the irue root cause 
rapidly and explain the symptoms, dependencies, legacies, 
and sensing tties isan art form and is deeply insight-based 

The root cause phase leads to the verification phase, in 
which the suspected fix is patched in and tested to see if il 
works in all cases, ( >tten design members will go hack to 
then design tools (simulators, etc. i to verify a fix because 
design tools provide a much richer method for controlling 
stimulation variables than the real world. It is hard to con- 
trol a l lain wreck! The design beam works hard to recreate 
exactly lite parameters that caused the problem, and then 
diey look for other related problems and symptoms, Unfor- 
tunately a patched lix often breaks the system in a new way, 
causing new problems lo occur. Or worse, the rOOl eaii.se 
was wrong and the lix doesn I ft i >rk. Then ihe nam starts 
over, having "wasted" time solving the wrong problem or 
only partially solving the right problem. 

Required Tools and Processes 

Tin- liine it rakes to solve these complex problems correct h 
is highly variable and highly sequential. Therefore, it is very 
hard I o predict or reduce this t&ne Systematically The VJU I 
ability comes from ihe inner loop, called the insight loop. 
This is where the engineers labor over the vast complexities 
and try to connect detailed hard wart 1 and software compo- 
nent-level understanding with rich and complex sequences 
and interactions. The engineering team must traverse from 
operating system to switching sequences to solve the prob- 
lems- Tin '\ need tools that traverse these levels of design 
hierarchy and ihe attendant complexity in a way that pie 
serves contend but reveals details, The engineer must retain 
detailed understanding hut in the context that describes the 
problem, always performing the deeonvolutions that slice 
the problem into the suhcontcxt This is the great challenge 
of the insight loop. 

The other reason toi ihe long integration time is thai prob 
lems an* uncovered sequentially. I >n<< problem is solved and 
then another is uncovered. An operating system nrusi In »oi 
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before a critical performance bottleneck <"in be discovered. 
A clock distribution problem must be fixed before a bus 
Liming problem is tackled, and so on. 

To be competitive, design teams must use the latest technol- 
ogies to get to the price/performance or sheer performance 
they need. The underlying technology pace causes the com- 
plexity, which causes the long integration phase. The design 
teams that master the integration phase are the first to mar- 
ket . since few companies have a sustainable advantage in 
underlying technologies. The winning design teams are able 
to master this phase consistently over several product gen- 
erations while bringing unique architectures and implemen- 
tations to important customer needs, Saving 20% of a design 
cycle may not seem like much, but doing this four rimes in a 
row places the team fully one generation of products ahead 
of its competition, a crushing advantage in today's electron- 
ics markets. This is illustrated in Fig. 6. With product life 
cycles in the 6-to- 18-month time frame, victors and van- 
quished are determined in just a few short years using this 
logic. The complexity is the Messing and (he curse, the en- 
abler and the nemesis for competitive market entry 

Design teams need processes and tools to manage this com- 
plexity during the integration phase so that they can, with 
confidence, take one step more in the use of modern tech- 
nologies without going too tar Reducing the tune to insight 
in the insight loop is how teams can musier complex liv 
rather than have it curse their design cycles with long and 
unpredictable times. The masters of the integration phase 
will win over the long term. These are the winning design 
teams. The tools and processes they need simultaneously 
provide insight into problem dependencies, reducing the time 
required lo isolate the context, and solve multiple problems 
ai once. Therefore, these tools musi retain context while- 
revealing details, and must nor hide one problem with tire 
symptoms of another. Without the right tools and processes, 
teams will suffer through multiple insight loops in sequence. 

The Hard Problems: Summary 

To summarize the nature of the hard problems and the de- 
bug process so that they remain in focus during the case 
study to follow, the hard problems are listed here in order of 



common occurrence and degree of pain to the digital design 
I eanv. 

• Hardware-software integration. Different tools used by 
different engineers. Very complex interactions. Data depen- 
dent. 

• Displaced locality. Symptom is separated from root cause in 
location and time. 

• Infrequent, Hard to repeat because of deep legacies in 
hardware and software subsystems. 

• Hidden dependencies. Underspecified components find the 
corner cases. 

The tools and processes needed in the insight loop provide 
the following: 

• Design hierarchy traversal. Details are shown m the unique 
context thai causes them. 

• Corrert isolation. The true and unique context of a problem 
is I'mmd i isi j 112 M'!|Nr j r?MaS exploHSfcory Logic:, S\ mph>m> air 
explained. 

• Correct root cause analysis. The component-level source of 
the problem is found. 

• Verification of proposed fixes, making it possible lo move 
on to the next pro hi em with confidence. 

■ Accuracy, One problem is not hidden with the symptoms of 
another. 

HP Workstation Case Study 

Following is a case study from an HP development to illus- 
trate the above principles. Hewlett-Packard is a heavy user 
of advanced technologies and tools to bring high-perfor- 
mance products to market. The product developments are 
typically organized in integrated design teams that effec- 
tively design complete products. Therefore, HP is a good 
place to look For the challenges and best practices associ- 
ated will] I he hard problems of complex systems. The case 
Study presented here is described in significant detail in 
reference 1. Here it will be used to illustrate the nature of 
the hard problems and the iterative debug process (the 
insight loop ] and the need to reduce the time Lo insight. 

The case study is from the HP workstation group. The target 
system is one of the HP 9000 Series 700 high-performance 
HP-UX* workstations. The block diagram is shown in Fig. 7. 




System Crash * — Ground 
Bounce 



Fig, 6. Ttifr '•uiTuiiative effect of reducing design cycle times from 
two years (bottom) to 1.5 years (middle) is equivalent to increasing 
the performance <tfeacji product generation, as exemplified :<;. the 
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Fig. 7. Block diagram of an HP workstation showing the location 

groimd biuinr-e causing the problem described in die case 

study. 
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It has a multiple-bus architecture with several custom AS 
and was designed specifically for high performance at a low 
cost During the final product qualification phase, an operat- 
ing system crash was found by a test engineer who was veri- 
fying various hardware and software configurations. The 
problem was infrequent and hard to duplicate. The system 
just crashed ai odd times. The test engineer called together 
a team of engineers with the ability to traverse the design 
hierarrh\ with arum en. 

The first step was to identify die problem correctly. The team 
found that the operating system crashed only when the - 
tern was performing DMA (direct memory access) transfers 
from a SCSI drive on the EISA bus. The next step was du| ch- 
eating and isolating the problem. It could have happened 
anywhere from the data source on the EISA card to the 
DMA cycle termination at the CP1." bus, To isolate the prob- 
lem, the data transfers had to he reduced in size and made 
repeatable. This is where the software team got involved, 
situ e i\n>\ could assisi in slicing the data sets into pieces 
that might recreate the problem. A binary search ensued, 
cutting and trying different data sequences until repeatability 
was achieved with a minimum failing sequence (MFS). Even 
this arduous trial-and-error process yielded only 90% repeat- 
ability. The 10% nonrecunence was ultimately (racked to a 
DRAM refresh cycle that changed the timing Of the sequence 
iluii caused the failure (all symptoms must he explained to 
ensure that a (rue root cause has been found. Often, teams 
will neglect inconvenient facts.) The team was now deeply 
in the insight loop, trying to find the sequences and context 
that would isolate the problem, leading them to the root 
cause. 

The ncxi step was to probe all data transfers from the EISA 
card into and out of main memory For this task, they needed 
a 1 ogi c analyzer and multiple, time-correlat ed . pro bing p oi n I s . 
They looked through many large ( IM-hyte) data sets to find 
the failing sequences. Comparing data across 1 1 u- bus bridges 
Is time-consunung, since the latencies are variable as a result 
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Fig, 9. The rr>nt cause af the problem was found with a high-speed 

' :■:-.'. :ll; m ■> p i Tim i<-r< uretated to the logic analyzer trigger looking at 
the error detecting logic in Mi- I '"'F'l 

of the intelligent queuing techniques employed in the bus 
bridge ASICs, Fig. 8 shows how the four bus transfers were 
observed to isolate the failing transfer. Finally, it was found 
tlutt the MFS was isolated to memory writes and reads 
aci i iSS the bus transceivers in the main memory system. The 
suspect part became a TTL bus transceiver, a common part 
"well-specified" by multiple vendors. The root cause of the 
problem was found wilh a high-speed oscilloscope time- 
correlated to l he logic analyzer trigger looking at the error 
detecting logic in I he CPL\ as shown in Fig. 0. 

The root cause was ground bounce inside the TTL part. A 
particular sequence of events placed ihe TTL part in a situa- 
tion where a write enable to memory was asserted and 
directly follower 1 1 >y ihe si m 1 1 1 1 at ieo us switching data transit »r 
erf" the entire byte i F|g, Ml). While this seems normal and is 
Indeed within specifications, tiie closeness of the switching 
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Fig. 11. HP im>BA in,.,:,,,. ,„, 



events, combined with the initial state conditions and the 
weak ASIC drive circuit nuances and memory system cap at - 
itive parasilics, caused a 2-to-3V ground bounce inside the 
TTL pari, Ttiis caused the part to open up both bidirectional 
buffers, which caused temporary oscillation, which caused 
data corruption. This corrupt dat^ when read back to the 
CPU many cycles later (several microseconds in a 60-MHz 
design), caused the operating system 10 crash. 

In the end. all symptoms were explained. Redesigned TTL 
pans were used and the memory system layout and the ASIC 
buffer design were improved. The breadth of experience and 
measurements needed to solve the problem was significant 
and is a true illustration of the insight loop. Vast data depen- 
dencies and odd sequences had to be explored and sliced 
through to find the MFS. Multiple points in the system load 
to be probed in time correlation. Data transfers had to be 
compared across bus bridges. In the end. the entire design 
hierarchy had to be traversed. from I he operating system 
crash to the ground bounce triggered by data dependent 
signal integrity. To solve the problem, the entire design ream 
had to be involved: the board designer, the ASIC designers, 
the software engineers, and the component engineers. 

The Prototype Analyzer 

The HP Model 1650SA prototype analyzer, shown in Fig. 1 1. 
is a prototyping tool designed specifically to reduce the time 
to insight into the common and complex problems plaguing 
complex digital systems. The prototype analyzer architec- 
ture is described in the article on page 15. It is based on a 
measurement server arc M lecture, described in the article 
on page 22. It is further based on the key concepts of smart 
data exploration, through a logically rich post capture 11 lin- 
ing capability, as illustrated in rhe rase study and in the ar- 
ticle on page 15. The key software technology that allows 
the product to present multiple time-correlated views across 
the design and measurement hierarchy is called normalized 
data and is discussed in detail in the article on page 30. 



The key concepts of the prototype analyzer product are as 
follows; 

Insight into problem sources comes from the lime sequence 
dependencies and is facilitated by sequential ordered explo- 
ration tools (filters). Therefore, time correlation, using 
global time markers, across measurements and across 
measurement domains is critical, Use of color and flexible 
user-definable data organization is required to aid the deep 
insights required to solve the hard problems. 
Most important problems are rare in occurrence. Therefore, 
tlie tool must quickly and intelligently filter out and elimi- 
nate large data sets that don't relate la the problem at hand. 
Furthermore, since the hard problems are rare, the tool 
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must be abip to keep data around to postpxocess in even" 
conceivable way to extract the maximum use from the valu- 
able captured data (the cause is in there someplace!). Avoid- 
ing the rerun penalty with its associated time delay keeps 
problem-solving times short, the way engineers need 

• Hard problems are solve*! by design teams, not by single 
members only. Therefore, the measurement server architec- 
ture needs to reside on the network and allow offline analy- 
sis by multiple members. Fig. 12 shows a common configu- 
ration of the prototype analyzer on a network, accessible to 

v design member. The easy communication of informa- 
tion across a local area network using standard file and 
server protocols facilitates team solving processes, Further- 
more, the tool needs to provide team-member-centric views 
appropriate to each person and problem. For this reason, 
the HP 16505 A prototype analyzer provides source-to-signals 
correlation, allowing correlated views from C source code 
to analog signals, all based on time-correlated measure- 
ments. The I6500B logic analysis system supports all these 
measurement mortalities. 

• Designers have vast intellectual property vaults in their 
design databases. These form the basic raw material for an 
engineer's analysis needs. They must be viewable and com- 
parable to the measured data to accelerate time to insight, 
A file m. file out capability facilitates the easy movement of 
the critical data sets to where they can be manipulated with 
the best postprocessing tools available, Engineers have 

I heir favorite tools and the prototype analyzer accesses 
them all through the XI 1 Window interface. 

• Large data sets are difficult to use to find (he elusive root 
cause of a problem even if the problem has been captured 
in the data set. This is because the user is overwhelmed by 
the magnitude of the data and has to wallow around in it. 
Overview tools are needed that transform the low-level digi- 
tal data and software code to a higher level where users can 
see the data that lies outside the norm. The human eye easily 
distinguishes such signals. The user wants to see changes in 
the data rather than just the raw T data. This higher level is 
called the modulation domain and is a specialty of the 
prototype analyzer with its ability to create new labels from 
combinations of raw incoming data. An example of this is 
shown in Fig, 13, I5te analyzer is used to extract setup times 
on a bus from the raw incoming data and clock signals. 

A new label is created from the difference between the data 
and the clock. This label can then be displayed as it changes 
over large time constants using the chart tool. A user can 
easily view a million setup times over several milliseconds. 
Dramatic changes of setup time at periodic intervals tell the 
engineer that the system timing margins are being stressed 
on software time constants, perhaps as a result of a DRAM 
refresh or tin- servicing of a periodic interrupt This display 
of the modulation domain is unique to the prototype analyzer 
among digital analysis tools and illustrates the power of 
postprocessing large data sets in overview displays to guide 
an engineer towards the Hnsive integration problem. 

Prototype Analyzer Solution 

Now we revisit the HP workstation case study to see how 
the protol ype analyzer ran solve this problem much fasten 
Tin ■ problem in ihe target system only occurred when simul- 
taneous switching occurred on the data lines with write 
enable followed quickly by Mala write changes (refer again 
to Tig, 10). Pig, lj shows how the prototype analyzer can be 





1 




Raw 
Data 

1 • 






New 
Label 




1 

i 


1 


1 




Da 

a 


la. 


Setup 
Date 


Data 
OX 


_j 


r~ 




u 


:-* 


v~ 




Setup 
Time 
Chart 


* 
> 




Jl 


• 






Fig. 13. In the modulation domain, changes in the data, rather 
than just raw data, can be 

analyzer extracts seiup times on a bus from the raw incoming data 
and clock signals and then displays changes in setup Lime usin^, 
chart tool. 

used with postprocessing Filters to isolate the case much 
faster. The prototype analyzer is able to filter out states that 
follow specific sequences, In this case. Filter 1 in Fig. 14 
could be set to view only the data for cases in which all 
states changed from ones to zeros (FF to 00) or vice versa. 
The design team suspected simultaneous switching noise in 
their design and this technique would have quickly given 
them the opportunity to explore this possible root cause 
without rerunning the target system. Any logic analyzer can 
find the first case of FF followed by 00\ but only the proto- 
type analyzer can scan an entire one-niegasaniple record, 
find all the cases where this is true, and display th$m all 
with the original data, time correlated with other views, such 
as analog data. Showing all the data, rather then Just trigger- 
ing on the first occurrence of this inmsition. allows the- de- 
sign team to find the one in a million limes that this transi- 
tion causes the failure, rather than having lo keep 
retriggering the logic analyzer, hoping to find this case. The 
next step is to filler again using a timing filter ( Filler 2 in 
F|g, 14). in this case ihr- design team is testing the theory 
I hat close timing between LEAB and data switching on data 
line A causes a narrow pulse, which, when driving the high 
capacitive load of the memory system, causes high ground 
currents. Only the prototype analyzer can find all of the 
occurrences of these conditions and only those that meet the 
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Filler I criteria. This consecutive filtering allows engineers 
l.o build isolation lechnkuies into their analysis to test their 
theories, rather than having to recapture the data and incur 
the ret rigger and recapture tune penalties. Using the oscillo- 
scope built into the HP 16500 B logic analyzer, they can cap- 
iujv with time correlation the lines that are being corrupted 
by the simultaneous switching noise and ground bounce. 
The time correlation allows engineers to retain the state and 
switching context that created the failing conditions. The 
waveform and lister tools merge the analog and code con- 
texts to form a new measurement domain. 

In summary, the prototype analyzer can be used to isolate 
the root cause of this problem much more quickly because it 
has sequential postprocessing filters, allowing analysis of 
entire data records at once. These kinds of problems are the 
cause of many delayed developments in advanced digital 
systems. The prototype analyzer tool is a way to solve diem 
mote quickly, minimizing time to insight for the design team. 

Conclusion 

Fig. 15 shows the use model for the prototype analyzer, re- 
drawing Fig. 1 to show how the risk in the concurrent engi- 
neering process can be managed with a single digital analy- 
sis loot platform to unravel the complexities of modern 
digital systems and deliver to design teams the tools and 



Fig. 15* tip dated system design 
process using the prototype 

analyzer. 

processes needed to roaster the integration phase to com- 
petitive advantage. 
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Prototype Analyzer Architecture 

The HP 16505 A architecture allows multiple concurrent views of acquired 
logic analysis data. Markers on all views are correlated. The user only 
needs to place the marker on one view and the markers on the other 
views automatically relocate. Thus a stack anomaly in one view can be 
immediately correlated with the software routine causing the violation. 

by Jeffrey E, Roeca 



The HP 1660&A prototype analyzer is the next-generation user 
interface for logic analysis. Ii is an XI I/Motif application run- 
ning on an HP 9000 Mc* le 1712 PA-RISC workstat ion directly 
tied to the RP L6500 logic analysis mainframe. This system 
is a managed, or closed, system. From boot until power-down 
this system is solely dedicated to extending the prototype 
debug paradigm from the nine-inch touchscreen of the HP 
16500 to a multiple- window, high-resolution interface. 

The design uses the XI I/Motif graphical user interface (GUT). 
This was done to accomplish several goals. First, using an 
existing state-of-the-art GUI allowed us to focus on our own 
contributions. Second, with the distributed XI 1 interface, we 
can make the application available over a network to any X- 
cnmplianl computer, including PCs. The software was written 
tn ( ++ for the Model 712 workstation platform. This gave 
our application affordable MIPS, which were needed because 
debugging one-megasample logic analyzer traces across 
hundreds of channels will lax airy computer. 

Architecture 

Fig. 1 shows a simple IIP 16505A setup. There are three tools 
on the workspace . Two tools are analyzer machines, and 
one tool is a display tool This simple configuration reveals 
the essential runclions. Tools ran be placed inr flow 

and run, The analyzers are lools thai probe togel hardware. 
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Fig. i. A simple HP L6605A prototype anaforaer setup Available 
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The A'orld data and the display tools indepen- 

dently view that data 

To deliver this functionality we have partitioned the architec- 
ture into the following blocks: 
» Tools. Tools are the atomic unit of value in the IIP 16505A, 
All meaningful user interaction is performed within a lool 
definition, 

• Acquisition Tools. The acquisition tool class is derived from 
die tool class. As Mir h it plays in the data flow workspace. 
The reason for making this a derived class lies in the way 
we connect or relate acquisition tools to the HP 16500 main- 
frame. 

• Data. All tools export and digest a common unified data 
format, 

• Workspace and Graph. The workspace is ihe visual pro- 
gramming GUI It allows tools, representee 1 by icons, to be 
connected to a data flow, represented by lines. The graph is 
the ordered list ot tools in ihe Bow, 

• Run Management This is a slate machine that pumps data 

I ho nigh I lie data fhm by executing the graph 

• General Support This is basically control or "glue" logic 

Data Flow 

Let s lunk a* an example data How through the architecture. 

When the user powers up the HP 16505A we begin an 
HP-I X i: Operating system boot procedure. Most of the hoot 
code is provided by the Model 712 ROM, Inn we adjust tttg 
daemons and hardware configuration fortius application. 
Once the operating system is minimally configured we call 

I I session manager routine, which never returns. The ses- 
sion manager handles software updates and spawning of the 
main application. This is also where the workstation is pen 
ered down. (The Model 712 workstation has a front-panel 
power switch, which Torres the HP-TW file system to be 
written tn ih>- S< SI drive before actually cutting power. This 
prevents the user from crashing the file system. Unplugging 
the workstation can lie problematic lor the file system. how 
e vt T . so ihe session manager has a power-down button to 
remind the user not to simply unplug the product J 

The real application begins as main c on HP-UX. We begin by 
neatin^ -in application content under the X Window System 

with a call to xtVaAppimtiaiized. The entire application runa as 
an \ 1 1 / Mi n i f application. From die ( i t ' 1 mouse/key b oard 
callbacks through (he acquisition control of the IIP 16500, 
;ill software is run as an XI I application callback. 
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The HP 16505A system software offers a handful of sendees 
fco tools '! i ices ;u>' collectively gathered beneath a 

si! neture Called tlie harue. The frame is one of I lie few gh ib- 
ally available pointers* Tools can access these system ser- 
vices by referencing frarne*>serv[ce. The frame services are: 

• ResourceMgr. Colors, fonts, cursors, path names. 

• RunMgr. State machine for stepping the tools through runs. 

• FileMgr. Storing and loading of configurations. 
° HelpMgr. Help screens. 

• Geometry Mgr. Pixel drawing management for the workspace, 

• Symbols. Definition and display. 

• FrameMarkerMgr. Global marker synchronization. 

• FrameMessageExchange, Mail sen ice between nodes on the 
graph. 

• TbcMgr. Manager of toolbox icons. 

• In strum em Mgr. Manages a list of instruments. 

• Admin Mgr. Networking and other HP-UX management. 

• Print Mgr. Print services. 

Next we perform a directory search for instruments and 
tools, All tools are compiled into shared libraries. These 
libraries exist beneath a well-known directory. We traverse 
the directories beneath this, searching for valid tools and 
instruments* A valid directory consists of a shared library, a 
resource hie, and a pixmap. The load algorithm is generic and 
does nut need to be rewritten when a new tool is created 
Simply creating a directory with these three files is sufficient 
for this algorithm to attempt to load. Tools are noted, but are 
loaded only when placed onto the graph. This can be oh 
served as a slight lime delay in the creation of the fust loo] 
of a given class. The benefit of demand loading tools is lhai 
the memory is kept free for deep trace analysis. 

Unlike tools, instruments are loaded when they are found, 
An instrument is an HV 1 15500. Within ihc HP ll>500lhere 
can be up to ten modules, bin there are not usually so many 
and it is efficient and simple to load them at power- up. 

Next the workspace is created. All of the loaded and noted 
tools are represented by icons in ihe toolbox, 

Next we start the File system, remote procedure call mecha- 
nism, messaging senites. and some other details. Finally 
we submit all processing to ihe X Window 1 System by calling 
XtAppMainLoopO- The application goes dormant until either a 
remote command or a GUI event activates a software call- 
back. Even the remote interface becomes an X event as w r e 
receive remote procedure calls and simply pass them along 
to the X Window System. When XtAppMafnLoop returns, the 
HP IG505A returns to the session manager. 

Tool Design 

Tools and their design are a major factor giving this platform 
room to grow. A tool is a ( ' + - class with a small set of pure 
virtual functions. These Junctions are: 

• getRev. What release of software (e.g., 1.20)? 

• about. Returns general tool information in ASCII format 

• save. Saves the tools configuration to a file. 

• load. Loads the configuration from a file. 

• add To Popup. Call from the workspace frame to add to a menu. 

• satName. Call horn ihe workspace to change diis tool's name. 

• raiseAiL Open up or raise the windows. 

• preExecute. Validates the internal state as legal to execute. 

• validate Conftg. Validates the configuration before Loading. 

• execute. Receives a new data group, returns a data group. 
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Fig. 2. Tool i lass lii'-niivliy. 

These tool him i i< uis are mostly mundane calls to get, set, 
save, or load static information within the tool definition. All 
real tools rnusi supply these functions, and the system glue Is 
written with calls through these functions from tool pointers 
kept in the graph. 

< inly one function deals wilh the primary objective ol a 
tool — passing data— and that is the execute fund ion. This 
function is declared as follows: 

virtual DataGroup * execute {const DataGroupi J 

= 0; 
A tool receives a call and is passed a pointer to the data mid 
labels. The tool can then interpret, filter or create data as 
needed All that is required is that the tool return a pointer 
to the output data group. This is very simple and powerful 
Compliance with the execution protocol does not require 
any co u p 1 i ng b e I w een t o 1 s . 

From tiiis definition all real tools are derived. Fig. 2 show T s 
the current tool classes hi the IIP 1G505A. 

Acquisition Tool Design 

The workspace manages an ordered list of tools. Conse- 
quently, a logic analyzer must be represented as a tool to be 
placed on the win kspaee. According to HP 16500 legacy, the 
fundamental working unit of a logic analyzer is a machine. 
A single MP 1(5500 card, or module, can have two machines. 
In the HP IG505A, each of the module machines is repre- 
sented as an individual tool in the toolbox, The abstract C++ 
class for t hese machines is called a probed source. Probed 
sources must address multiple complications. One is com- 
munication with the HP 16500 module. Another is handling a 
workspace presentation that represents probed >oiirces as 
independent tools, while behind the scenes both machines 
of a single ]\V 16500 module are joined at the card. Another 
complication is i ■oordinaiing the remote acquisition of data 
Fig. 3 presents Ihe acquisition tool hierarchy, showing the 
basic composition of probed sources mid their relationship 
to their module (card) and the HP 16500 (enterprise). 

The class that is placed onto the workspace is one of the 
machine classes. Because these classes are derived from the 
probed source class, which is derived from the tool class. 
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I hey can be inserted into the workspace. As previously 
Stated, a logic analyzer card can have multiple analyzers, or 
machines. Accordingly, each machine has a relationship with 
its parent card class, which is derived from the abstract card 
class. Cards in turn are owned by tin ra qnisition enterprise. 
The enterprise dflSS is derived from T tie abstract instrument 
class. Within the instrument class exists the transport 
knowledge, which happens to be SCSI. 

Encapsulating the SCSI transnon in the instrument e 
allows us to port the transport layer with a minimal impact 
on the rest of the software* This was a benefit in the initial 
stages of development when the SCSI interface did not exist 
and we progranuned the HP 16500 over the HP-IB (IEEE 488, 
IEC 625). 

By using the existing ASCII programming strings of I he HI' 
L 65(10 we are able to acquire data in an existing stable pirn 
form. By using the SCSI transport we minimize the latency 
of transfer from the HP 1060(1 to the HP 16f>05A. 

Data 

Data is different for each analyzer can [ in t In 1 1 f ' I r>r>ou. 
Historically this slowed development by giving rise to 
custom, hardware-specific algorithms to render that data. 
Behind similar HP Iboxx interfaces may be completely dif- 
ferent software. Fig. 4 shows the transform that we apply in 
the HP 1 6505 A prototype analyzer. As data is uploaded from 

HP 1650EA Prototype Analyzer 



the unique hardware, it is transformed into a common, or 
normalized format. This normalized daia is what all tools 
downstream from the analyzer source operate upon < see 
article, page 30), 

Workspace and Graph 

The primary role of the workspace is to construct the data 
flow relationship thai is executed during runs. The data 0ow 
is constructed with tools and data. The Gil provides a tool- 

thai Contains icons representing all available t 
A user drags an icon representing an available too] 
toolbox and drops it into the workspace. Data flow is repre- 
sented by lines connecting the icons or tools. Bach tool that 
is placed onto the workspace is entered into the graph, The 
graph is an ordered list of containers. A container is a struc- 
ture that holds information about real instantiated tools. Any 
software function can execute the graph, which results in an 
ordered delivery of containers bottle requesting function. Hie 
function can then call the appropriate tool function through 
the container. 

The graph has a simple set of rules detemuning the order of 
execution of the list of tools; 

* Only tools that are on the workspace are executed. 

* Orphan tools — tools rhar have no data connections — are 
executed Ursi , 

level tools such as logic analyzers and oscilloscopes are 
executed next. 
■ The graph does not transition from one level to the next 
until all tools at a given level are complete. This ensui 
that any tool that receives data from multiple sources will 
have the data available when the tool is executed, since all 
parent tools must have completed before the tool is called. 

Fig. 5 shows a workspace representation with three analyzer 
machines, two filter tools, a lister, and a waveform tool Ml 
and M2 are merging their Independently acquired data to- 
gether into a single data group and then passing that merged 
data group through (he Filter 1 tool to the lister \U is an 
independent data group that passes through Filter2 into the 
waveform tool. There are highlighted boxes labeled level l t 
level 2, and level 3. These boxes indicate the order of execu- 
tion of I he graph. Level J tools are t he data sources, or ana- 
lyzer tools, This level is executed first. No tool in level 2 or 
level 3 will execute until all level 1 tools are complete. Once 
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Level 1 is complete then the level 2 tools will execute. No 
tools in level 3 will execute until level 2 is finished. This is a 
general rule: level N-l must finish before level N executes. 

Run Management 

The run manager is the software that pumps data through 
the graph. It is a state machine that executes the graph 
Remember that execul ing the graph is an ordered, level-by- 
level event. This ordering allows for all probed sources to be 
Configured, started, and uploaded as a coordinated group. 

Fig. 6 shows the states and their execul ion cycle, together 
with ihe entry points into the state machine. The states are: 

• PrefiunDownload. The IIP lt>505 A probed source software main- 
tains internal configurations. The GUI modifies the configu- 
rai ions and the changes are stored in the IIP 16505A without 
remotely updating Ihe IIP 16500. When Run is pressed, a 
probed source is requested to download lo lite HP Hi'.ihi ihr 
current: HP 16505A probed source configuration. 

• Pre RunCheck. A given HP 16500 card may have an illegal set- 
ting Ui at prevents a run from proceeding. This state allows 
the HP 16500 status to abort a run, 

• StartAcquisrtFon. The HP L6500 is start eel. The current release of 
the HP L6606A only performs group runs. A group run is one 
that time-correlates the trigger events from participating 
modules. 

• WaitmgFarCards. The HP 165U5A polls the HP 1(3500 run status 
waiting for Ihe run completion* 

• UplaarJingNonnalizing. Each card is called serially to upload and 
normalize the acquis! I ion data. 

• TimeCorrelating, After each card is normalized the system 
acquires the tuning correlation values and updates the 
normalized data. 

• DataExecution. The normalized data is now passed through the 
graph to the configured tools. Each fool called will render 
the data and update its display. 

• PostExecution. The IIP 16505A does some cleanup. 

The graph is executed during each state at least once. A given 
state may only choose to communicate with a tool if the tool 
is a probed source. A state may execute die graph mull iple 
times. For example, WaitingForCards is a state thai can take a 



significant amount of time, depending upon the repeatability 
and cycle time Of the trigger specification. The rim manager 
could be stuck in this state forever. The logic within this state 
executes ihe graph. If ihe raids are not complete then the run 
manager sets an X riineoul and exits. 

The setting of the X timeout is sigruficariL It is essential that 
rhr GDI is allowed to run to service potential stop events. At 
the first release there is no remote control of the IIP tfiSGSA, 
and a GUI event on a stop button is the only way to abort a 
run. 

Example Control Flow through the Software 

Fig, 7 shows a simplified control flow for acquiring status 
during an acquisition of data. A user has previously pressed 
the Run button, which starts the run manager state machine. 
In this example the run manager has been called (from an X 
timeout) and is processing the WaitingForCards state. This stale, 
like all run manager states, calls the graph execute function. 
This causes the graph to cycle through all of the tools on the 
workspace. The run manager calls tools thai are probed 
sources request Ing their status, Now is where the mapping 
of analyzer machines, or probed sources, to cards becomes 
important The HP 16500 remote control is ordered by mod- 
ules. Within a module, communication is with an analyzer 
machine. The IIP 1(3505 A has requested the run status of an 
executing machine. This request is passed to the parem card 
class. The card knows which HP H350O slot to select The 
card also knows what messages to apply to obtain I he status. 
These ASCH HP 1(3500 command si rings are then passe* I to 
Ihe enterprise, or IIP |fJ.">iKi6 (lass. This is ihe class that 
inherits from (he absiracl instrument < lass. The SCSI In ins 
porl sends the ASCII programming instructions down to the 
HP IboOOH and there they are parsed and interpreted 

Fig, ft shows a similar simplified block diagram with Ihe 
normalized data, tools I bat are not probed sources, and the 
tool support blocks added. Ignoring the fine details of the 
myriad ol support tools, correlated markers, and so on, one 
can obtain a good understanding of the HP 16505A architec- 
ture from this figure. The frame object has a run manager 
object which controls the state machine for acquiring and 
pumping data through the tools. The workspace has an 
ordered Iisl of instantiated tools and controls the execution 
order. Tools are either independent loots or probed sources. 
If i hey are probed sources they communicate through their 
parent card through (heir instrument through ihe transport 
layer, Probed sources generate normalized data, and all 
Other tools can use, modify; and generate normalized data. 

Examples of Visualization 

Tire primary value Of the HP 16505 A lies in its ability to help 
Ihe user visualize dala. The architecture was defined to allow 
multiple concurrent views of the acquired data. By slicing and 
dicing data in different ways, fault isolation becomes easier. 
Fig. 9 shows an IIP I(i505A setup demonstrating how visual- 
ization in multiple views promotes rapid time lo insight Soft- 
ware stack corruption is a difficult problem to solve, Tsually 
a corrupt stack does not directly reveal itself More 
the product crashes far away from the actual write violation. 
In Ibis example a 08332 microprocessor running software 
has been sampled. This data has been displayed both tmfil- 
tered and filtered, The filtered data is shown in ASCII formal. 
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as a chart, and as a distribution. The filtered data in cfoan 
mode shows the stack as a function of time The niier is a 
simple range between the low and high boundaries of the 

stack, Visually one can see an anomaly in Mir slack spare. 
In tills example ihe write taking place beneath the Gl marker 
in the Stk vs. Time window Ls in error. By looking at (he ASCII 
listing of the imfilleird rial a in the Raw Trace wincinw we can 
see exactly what software was executing at the time thai 
this erroneous write to ihe Stack Space took place- 
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The IIP 10505 A allows these multiple views- du* lister and 
the filtered chart — to he displayed concurred Uy. Within ihe 
HP 10505 display tools we have correlated markers. The 
default behavior of a display tool is to track the placement 
pi a marker automatic -ally. The user only needs in place ihe 
marker on the visual stack anomaly, and the lister anion iaii 
rally relurates itself 'to reveal Ihe software routine in viola 
lion. 



June l998Hmv!Hi l»j*ek;irr| .li.oLrnal IH 



)Copr. 1949-1998 Hewlett-Packard Co. 



HP 16505 A Prototype Analyzer 
Frame Workspace 



Hun Manager 



Stale machine 
controls data flow 
through the graph. 



Tool Support 





Normalized Data 



Data Group 1 



Instrument 



I 



Data Group 2 



Data Group Y 



Enterprise 



Pnrenl Card 1 



upload! I 
seniUS ELI 1 
MUorylDATA?} 




To HP 
16500" 



SCSI: 
query 



Parent Card J 



liliUiarlil 

> S£L ID} 
query! DATA?! 



TeolV: 

Pruned Source N 



Fig. 8. Simplified block diagram 
similar fit Fig. 7 with normalized 
l;n,i. Tools I hat are not probed 
siHjrres. and tool support blocks 

i.| !- ■ i 



20 June 1S*F»G ltewl erf-Packard Journal 



)Copr. 1949-1998 Hewlett-Packard Co. 





^H illilll 


■H 


Data Valuai 


44J W 


I_l 


Percent oF total 




Hifh Value 




"-mid* 

O Accumulate 


Clear | 







v - m V = 44176 




1^* & An HP 16505A setup demon : tck corruption problem ththeW 

iiuirk.-r itrlJu-StkvS.Time v.jm.Ii.vv i- in ' M-? I ;■, |... .hi.- ai ■■ fftfoeunflJtfeTi I ifagi • ta Mm- Raw Trace vvim i^ . 

cuting at the time that tli write to the stad pace took placi Then ed '• pte 

the visual stack anomaly, ami the Ik ter atHomatfcaJb relocates itself i e software routine m Ldlation 



Ac k 1 1 owled gme n ts 

The author would like to acknowledge James Kahkoska fur 
defining, designing, and driving ih< 1 pmijun tdea feted reality 
uht also like to thank Mark Schnaible for helping cttsUll 
i he HP 16805A architecture down to a fe^ slid 

intfanon in ] fie U S A and mfrer cmintrras. 



NP-UX9* and IDOL' ■ :^ny UNIX 93 

branri' 

S a fegisteren • s-jcl Stales and I 

•i Company Limited 

, 
I imited in the UK and oiher countries 



■hmo t!«Hi!ti'\vU'Tr Packard Journal 



il 



)Copr. 1949-1998 Hewlett-Packard Co. 



Determining a Best-Fit Measurement 
Server Implementation for Digital 
Design Team Solutions 

Prototype analyzer customers wanted fast throughput, quick answers, a 
turnkey solution, an affordable base system price, connection to diverse 
open-systems networks and platforms, and interfaces to a wide variety of 
tools. An encapsulated measurement server architecture based on a 
dedicated workstation and a SCSI II interface best fit the requirements. 

by Gregory J. Peters 



Implementing an analysis and display architecture for the 
next generation of HP logic analyzers presented opportunities 
and challenges for the cross-functional design team assigned 
to the task. Freed from the boundaries of commercial real- 
time instrument operating systems and needing to offer a 
flexible and high-performance window- based interface, the 
project team took a long look at both technologies and the 
total envelope of costs before settling on an encapsulated 
measurement server architecture based on an HP yQIXI 
Series 700 workstation. 

The goal of the IIP 16505 A prototype analyzer team was to 
develop a breakthrough analysis and display environment 
for digital design leaius involved in the integration and debug 
Of prototype systems. The resulting product is a combination 
Of the best of traditional instrument and system benefits. 
The turnkey prototyping system provides Ifce performance 
and flexibility demanded by leading-edge digital design teams 
but its low total system cost appeals to the smaller teams as 
well. The tough decisions made very early in the product 
definition phase have paid off. The product meets market 
needs and has a low cost of sales and support envelope. 

Genesis 

The genesis of the prototype analyzer occurred with the 
realization that digital hardware developers, who are tradi- 
tional logic analyzer users, were spending an ever higher 
percentage of time using electronic design automation 
( EDA) tools, such as schematic capture and simulation soft- 
ware packages. The use of workstation or PC -based EDA 
tools came at the expense of time spent in the lab making 
measurements on prototype hardware. 

The workstation or PC w;cs lUst becoming home base for 
designers. Traditional rest instrunientaiion was in danger 
of becoming less relevant to the design team, in large pari 
because it didn't interface with EDA tools. The question the 
team pondered was how future real-time measurement sys- 
tems would interface with the designer's workstation home 
base. 

Tills concern generated an investigation into workstation 
connectivity, and the prototype analyzer project was horn. 



The development team at first conducted research wilh hun- 
dreds of customers worldwide, in different industries and 
with different measurement needs. The results of I he inves 
tigation drove the definition of the prototype analyzer mea- 
surement server implementation. 

Measurement Servers 

Measurement: servers are defined as a class of solution that 
combines physical measurements with client/server comput- 
ing. Real-world measurement data is captured, analyzed and 
shared with users and other tools over the network using a 
variety of open-systems standards. 

Measurement servers use widely accepted networking stan- 
dards Such as Ethernet, the X Window protocol, and the 
Netw T ork File System (NFS) to enable customers to control 
and view measurement instruments and get easy access to 
measurement- data. Standard data formats are used to inter- 
connect the measurement server with other applications, 
Specialized host-based software is not required Measurement 
servers can provide anywhere, anytime access to prototype 
measurement data via today's ubiquitous networks. 

Client/server computing enables each component of the 
system to specialize in what it can do best. The locations 
and definitions 61 Ibe interfaces between components are 
determined by the nature of the application and the network 
topology. A well recognized example ol a client/server appli- 
cation can be found in the KDA industry: a simulation engine 
runs on a large compute server while the simulation inter- 
face runs on the engineers desktop. Application developers 
must pick the appropriate points to split apart an application 
to maximize a product's performance and value. 

Measurement server architectures vary depending on the 
scope of the solution. Some architectures are completely 
encapsulated inside a box T while others are split apart or 
distributed i see Fig. 1 ). Identifying the appropriate point to 
split the application apart is critical. Splitting an application 
iti i lie wrong place can limit response time* or rausc n on de- 
terministic behavior. Encapsulating the wrong functionality 
into a system can increase the cost of the system or the cost 
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of sales without increasing revenue. Encapsulating too little 
functionaliu m.i\ result in trivial or redundant products, 

The full use of the client/server paradigm is the differentiating 
aspect between Traditional instruments '-and measurement 
servers. Traditional instruments can also be connected to 
Computers via the HP-IB (IEEE 488), bill this i-nnnectiou 
requires special interface' and control hardware and aofl 
ware on the host computer. Additional analysis arid display 
software is generally custom, and can be time consuming to 
lop and delnig. The localized nature of the HP-IB limits 
Ms penetration into open computing environments and the 
need for specialized control and interface software puts 
HJMB-cont rolled instrumentation at a distinct disadvantage 
in the networked design environment. 

Architecture Selection 

To obtain the best price and performance trade-offs, the 
i u • <| >osed solution must be evaluated closely to determine 
Hie optimal measurement server archi I ft foil v. The Mn- 
examples given below highlight some of the issues thai must 
be addressed. The prototype analyzer development team 
was able to gain valuable experience from reviewing each of 
these product forms. 

An example of a distributed measurement server architecture 
can be found in (he IIP B3740A software analyzer This soft- 
ware package provides s< ifl spare I le\ eil ►pers With a means of 
viewing real time mien (processor traces referenced to 

S0M&C julr The HP B-1740A runs on several workstations 

mid on I 



The host-based nature of this application w r as derived from a 
nee ! u • soi in reviewing functionality to a large num- 

ber of design team members who timeshare a single real- 
time iust run hmI (the HP 1650GB logic analysis s\ si en n. 
In this case, ihe small amount oJ data transferred over an 
Ethernet link between the IIP IboOOB and 1 1n- IIP IJHT-JOA 
does not impart performance. Performance here is inea 
sured as update rale. 

\s a point application, this product does not require exten- 
sive support. If the same approach wen' taken for several 
applications, however, the sales and support burden could 
limit broad market penetration. In particular, maintaining 
host-based software on a platform that has frequent operating 
■ \-h'm revisions is nut only r hue-consuming but also results 
in a low return on investment to Sie development team. 

IIP VEE, a visual prograiuming and test development envi- 
ronment.- besi illustrates a mixed measurement server 
architecture. HP VEE runs as a host -based program on PC's 
and workstations- This product enables engineers to quickly 
develop lesl programs that control a wide variety of inslm- 
rnenls over the IIIMMon a standard c< imputing platform such 

as a workstation or PC. The key benefit of this approach is 

the flexibility afforded both solution providers and end users. 

A choice of supported platforms means customers can use a 

platform they are familiar with. An open system development 
environment enables \alne added engineering, upon which 
solution providers can build nisiimi applications. 
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A mixed measurement server architecture has drawbacks, 
however Maintaining a reliable interface between the hosfc- 

based software and the measurement instruments through 
operating system revisions or changes in network protocols 
can be challenging. Setup and maintenance of a distributed 
system require significantly more effort than a turnkey 
instrument. A dedicated Ethernet network can impose band- 
width barriers that severely limit measurement throughput 

The HP 1G500B logic analysis system with an HP 16500H t L 
interlace module Ls an example of ait encapsulated rrteasi Mo- 
ment sender. This system can provide both local and remote 
control and viewing via the X Windows protocol. The turn- 
key nature of this product makes installation and setup sim- 
ple. Since all data processing takes place in the instrument, 
only X Window calls are transmitted over the Ethernet. This 
helps feeep the update rale fast over most network topolo- 
gies. 

W T hile the support burden of an encapsulated measurement 
server is low t it comes at a price. User- defined measurement 
sequences and extended data analysis and reporting are not 
provided. Customers must make a connection to the HP 
1G50GB and import data and screen images into a general- 
purpose computer to perform these tasks. 

Considerations such as customer expertise in open systems, 
support costs, and the use model for the product must all be 
factored in when choosing ait architecture §6i a measurement 
system. Trade-offs must be made to fit I he needs of the mar- 
ket and target customer. Table 1 outlines the advantages and 
disadvantages of the tltree measurement server arctatectural 
approaches. 

Customer Requirements 

The workstation connectivity investigation generated an 
extensive set of customer requirements. These inputs 
spanned the entire realm of product definition, from tech- 
nology needs through user disciplines and measurement 
tasks. The investigation revealed: 
« Prototype measurements are essential for hardware/soft- 
ware integration and product verification. 

• There is a wide variety of use models, from the bench top 
standalone user n> completely networked Control and 
viewing of measurements from a remote she. 

• An analyzer might see single-person use or shared use by 
teams of as many as 50 engineers. 

• There Ls a strong desire for a turnkey system, not a collection 
of components that must be integrated by the customer. 

• Equipment setup time must be a minimum. Customers want 
to be able to make a connection to the prototype and make 
measurements as soon as possible. 

• There is a broad university of measurement needs, from signal 
integrity to software, and across a variety of probed points, 
from serial buses to RISC processors. 

• Surprisingly, we found the potential to address a broader 
group of customers than envisioned before the investiga- 
tion, including software developers, who traditionally 
avoided the lab and used host-based software development 
tools, 

• We heard a strong request for snappy displays and quick 
measurement results (facilitation of the debug lo« >\ i 
explained in the article on page 6). 



Table I 
Measurement Server Architectures 

Advantages 

Distributed 

• Fastest leverage of I inks to other host-based applica- 
tions, 

• Most efficient at using customers available ((imputing 
power (MIPS), Takes advantage of idle MIPS on 
customers host computer. 

• Low msr of goods sold (software only). 

Mixed 

• Provides best mix of flexibility and power for custom 
sy st e m devel opment , 

1 ie st 1 1 1 r i 1 1 1 eg rai i it g ( 1 i ffe re i it measurement sy st ems. 

• Deterministic performance can be achieved over a 
dedicated network d IP-IB). 

Encapsulated 

• Turnkey solution (ready to run). 

■ Very high measurement throughput 
» Deterministic performance. 

• Low cost of sales. 

• Low cost of support 

• Low R&D resources required to support and enhance 

I he system. 

Disadvantages 

Distributed 

• Low measurement throughput. 

• Nondeteriuinishe performance (Ethernet). 

• Requires continuing R&D effort to maintain support on 
new operating system revisions. 

• Requires extensive and time-consuming QA on 
supported host platforms. 

■ Requires some customer operating system ami I < I 
knowledge. 

• Higher support costs than encapsulated solution, 

Mixed 

• Requires special dedicated network hardware and si »h 
ware. 

• Requires customer operating system, I/O, and networking 
knowledge. 

• Throughput can be limited (depending on the perfor- 
mance of the dedicated network). 

• Requires continuing R&D effort to maintain support on 
new operating system revisions. 

• Higher support costs than encapsulated solution. 

Encapsulated 

• High cost of goods sold 

• Fixed functionality. 

• Low- efficiency of using customers available MIPS. 

• Requires some networking knowledge. 

• The solution must interface with a wide variety of design 
tool chains, consisting of EDA software programs, test 
development programs, and others 

• There is a desire for connection to diverse open-systems 
networks consisting of nearly every possible combination of 
computer hardware and operating system software on the 
market . 
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■ Tlie base system must be affordable to reach most users 
and scalable to cover both performance and mainstream 
users. 

■ The Ethernet protocol was in use at most customer sites. 

Taken together, these inputs overwhelmed the project team, 
Scaling the task to available time arid resources becanit 
critical project goal. Reducing the dimensionality required 
of the architecture would be the key to deHvering an on-time 
product that mei key user needs. 
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Demographic Far tore 

Digital design learns of all sizes are found in every indus- 
trialized country. Design teams as small as two engineers 
expressed many of the desires listed above. Because of the 
broad demographics of digital design teams, a key challenge 
was offering a low cost of sales and support product struc- 
Hire to fit a sales channel that could reach these customers. 

A complex product structure greatly increases the cost of 
sales and suppon, A high cost off sales makes broad product 
adoption difficult. This is because complex product struc- 
tures typically demand a specialized sales and support orga- 
nization, which in turn limits coverage both geographical^, 
and at smaller accounts. Product specialists are expensive 
because of their training and expert knowledge, but also 
because it is difficult for them lo cover the same geographic 
area as i horoughly as a group of generalises who make daily 
contact with a wide variety of customers, and who sell a 
wide variety of products. 

Product generalists are far more likely to make contact with 
small customers. These customers are less inclined to pur- 
chase a system they view as so complex that a specialist is 
required to sell and support it, Creating a product that de- 
mands product expertise and specialization of a sales force 
directly contradicts ihe fact thai design teams of all sizes 
and budgets have many of the needs listed above. 

The resolution of this issue became a focal point of the 
prototype analyzer product structure. The outcome of the 
measure] i ui li server architect nte decision would be the 
major contributor to the cost of sales. Reducing the dimen- 
sionality of the product would help lower overall costs and 
allow the product to be sold and supported by generalists. 
not specialists. 

Issues 

The four issues that most affected the choice of measure- 
ment server architecture were: 

• Fast throughput and quick answers 

• A desire for a turnkey solutipl \ 

• Ati affordable base system price 

• Connection to diverse open-systems networks and 
platforms and interfaces to a wide variety of tools, 

The additional requirement that was used as a starting pokti 
for the design was thai I he producl must work with existing 
IIP 16B00B systems and measuremenl modules. The design 
team was to create a product that added functionality to t lu- 
ll P 1660GB system but did not require customers to make a 
•jiitl' .uit 1 11 w investment in real i inn i acquisition hardware- 
Work on the core software architecture began independently 
of the measurement server decision. The four isstu m n 
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Fig. 2* HP 165G5A prototype analyzer measurement server 
ii 1 1 pi i -mentation. 

used as a basis for discussion about the pros and cons of 
each measurement server architecture. In the end, an encap- 
sulated architecture was chosen, as shown in Fig, 2. 

Throughout 

Throughput was a key element of the prototype analyzer 
design. A customer set a benchmark for t:he design team by 
staring the expectation that a fu II screen of IIP 16550A data 
should be refreshed once per second. This became known 
as the "one update per second" goal and was used as the de 
Facte 1 hroughput benchmark. 

Table II outlines the amount of dala that some HP 1650GB 
logic analysts system measurement modules capture in one 
acquisition. The italic numbers indi< :m ■ mi union configura- 
tions. These configurations were used in ad hot tests by 
R&D to evaluate the update rate as the software architect ure 
progressed. 

A single acquisition covering several microseconds could 
generate as much as 30M bytes of data. Sending this ann mm 
of data over a customer's local area network would be im- 
practical and would cause severe network performanee 
problems- It was Obvious that some sort ul dedieafed net 
work would be required to move data quick ly from 1 lie III 1 
16500B system to a workstation or PC for dala normaliza- 
tion and display 

The real-time nature of the system implied a robust and 
deterministic interface. Handling real-time I/O across open 
networks without the benefit of a well-defined protocol is 
difficult, and would require special driver* mi both ends of" 
tin- network, Porting real-time cork 1 across plat forms would 

add complexity to the design* 
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Table II 
Typical Measurement Data Sets 

HP 16500 
Measurement Module 1 Module Z Modules 3 Modules 



HP 16550A 500-MHz 


5^K 


110K 


N/A 


Timing 100-MHz Slat**, 


\ t\ 1 i >s 






JK Depth, 








100 Channels 








HP 16555A 500-MHz 


8M 


16M 


mm 


Timing 110-MHz Stat e ? 


bytes 


bytes 


bytes 


IM Depth, *>4 Channels 








HP 16532A 1-GSa/s 


16K 


32K 


48K 


Digitizing Oscillo- 


bytes 


bytes 


bytes 


scope, 8K Deep, 








2 Channels 








HP16517A/1KA 


128K 


-J-iiK 


384K 


4-GSa/s Timing, 


hytrs 


bytes 


bytes 


1-GSa/s Stale. r>JK 








Deep, 16 Channels 









Leveraging analysis done by HI* Laboratories aud other divi 
sions, ;i the design team was quickly able io evaluate interface 
performance characteristics. Table HI provides a comparison 
of different interfaces and the estimated throughput of each. 
Data handling in the HP 10500B and normalization time in 
the HP 16505A is not included in these figures. 







Table III 
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Transfer 


Transfer 




Maximum 


Typical 


Time for 


Time for 




Transfer 


Transfer 


110K Bytes 


24M Bytes 


Interface 


Rate 


Bate 


of Data 


of Data 


HP-IB 


1 Mbyte/s 


240khyles/s 


0. 17 g 


100,1 s 


Kihernet 


I Mbyte/s 


m\ kbyles/s 


0.:JSs 


80.7 s 


SCSI n 


5Mbyles/s 


L5 Mbyles/s 


0.07 s 


15.27 s 



A I i \ 1 1 1 n t> 1 1 al 1 1 h ree i n ( e if ae es pe rf on u th e 1 1 OK-byte I ransf er 
in less than 0.5 second, I he SCSI II interlace offered a sub- 
stantial improvement in performance, which would be 
needed when transferring the SOM-feyte flies found in high- 
end HP logic analysis configural ions. 

SCSI II was not the first choice of the design team. The HP 
16500B already had HP-IB and Ethernet ports. Adding a 
SCSI port would take more time and resources. Some team 
members argued thai HP-IB performance could be im- 
p rove d . II owe ver, The HP-IB i uteri ace would then reqi i i re a 
corresponding connection on the other end. Since work 
stations and PCs don't come standard with HP-IB interfaces, 
the use of ibis port would require special hardware for the 
host computer. No one relished the task of designing a 
computer-based HP-IB card or evaluating the commercially 
available cards, 

Ethernet was a clear winner from a user perspective and an 
Ethernet port was available on the HP 11VS00B. The two 
strikes against Ethernet were its performance compared to 



SCSI II and its inherent nondetermiiusl tc behavior, a result 
of the collision detection and retransmission scheme used. 

In l he end. the S( SI II port won out In retrospect, the use of 
rln j fastest interface available was an excellent choice, since 
HP IfiftOOB data sets continue to grow in size and customer 
throughput expectations constantly increase. 

As the design beam developed i he software architecture, it 

became apparent thai there were many areas w here rude 
optimization could improve throughput, A problem with 
software optimization Lslhat 11 is often dependent on the 
architecture of the underlying hardware- Although the team 
was using the HP 9000 Series 7(H) workstation as a develop- 
ment station, a platform choice had not yet been made. One 
factor i hat swayed the development team in favor of an en- 
capsulated measurement server was their feeling that signif- 
irant improvements to performance conk I be obtained by 
inning the soft wan' architecture to one computer architec- 
ture. This inflight proved fori nil ous because the k&l'Heain 
got the chance to optimize the architecture and gain a lOx 
performance improvement when the coding was complete. 

The decision to use SCSI II meant that a distributed mea- 
surement server architecture would not be feasible, since 
SCSI is not a network protocol. 

Turnkey System 

With the interface issue settled, the design team began in- 
vestigating dedicated controllers. Both workstations and 
PC's were evaluated. Each platform had advantages and dis- 
advantages, as outlined in Table IV. 

Table IV 
Controller Comparison 

Advantages 

Workstations 

• Highest single-processor performance available 

• Standard SCSI interface 
■ Good networking 

• Good development environment 

• Can act as X client or server 

• Excellent graphics support 

PCs 

• Good performance 

• Generally lower cost than workstation 

• Excellent development environment 

• Customers familiar with Microsoft Windows® 

• SCSI interfaces available 

Disadvantages 

Workstations 

• Higher cost than PCs 

• Many customers not familiar with HP-UX* operating 
system 

» Potential for file system conniption 

• Requires more base system memory 

PCs 

• X client software not readily available 

• Acceptable but nor robust networking 
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An important factor in the o- i workstation 

and a PC was the ability of a workstation to operate as both 
an X client and an X server. Since customers demand both 
local and remote viewing and control of the prototype ana- 
lyzer. X Windows was a necessity. In general, PC-based oper- 
ating systems did not support this function or handled v 
it! case. 

However, a problem with the choice of a workstation w 
tile HP-UX operating system. Many customers were not 

jar with HP-UX and did not want to learn it. Seeing an 
HP-l X prompt - Tern w ouW a problems for 

HP's general-purpose sales channel, who were gene? 
unfamiliar wirh the I T NIX " operating system. 

The team decided to create a complete turnkey system on 
top of the operating system This meant ihan.lv 
could nut he used to nm other HP-l X applications or as a 
general-purpuM' computer While rh» j implementation of this 
policy was nni lechnicalh difficult, explaining the concept 
took considerable effort. The team found thai since there 
were many existing models of mixed measurement server 
systems, the natural conclusion was that the prototype ana- 
lyzer would also be open for customer development The 
level of communication required to explain that the proto- 
type analyzer would be turnkey was much higher than antic- 
ipated In the end, the team found that demonstration was 
by far the most effective way of communicating the product s 
structure and its advantages. 

An added benefit of offering a turnkey system was that the 
team did not have to worry about operating system revisions. 
Maintaining an Open system would require the team to put 
ongoing effort into supporting three opt rating systen revi- 
sions; the last, the current, and the future. 

The prototype analyzer is built upon only one operating 
nil i iv\ isiniL The entire system will be re* ised only when 
customer needs change and substantia] new functionality is 
required. This frees the design team from chasing operating 

system revision-related product defects. 

Meeting Price Goals 

Research indicated thai while customers wanted a powerful 

analysis and display environment, their perceptions of price 
wriv influenced by the availability of PG ami workstation- 
based data analysis packages thai sold in the i f,S.$1000 io 
sruMK) raiiiie. i ustomers ;i!sc. viewed the prototype analyzer 
as a i< i 1 1 ■ I of operating system. I Operating systems aren't val- 
ued as highly as the applications fliaf run on them. 

This data implied that the total system price would need to 
be in the range of U,S,$5000, The design team had two areas 
where costs could be lowered. The workstation would rep- 
resent a large portion of the prototype analyzer material 
cost. Selling and support expenses also contribute to the 
total system cost. 

Concurrent with the prototype anatyzet development, HPs 

Works! at ion < i roup was desimhn^ the HlMHlliO Model Til! 
low-cost Workstation. A review of the workstations price 

and performance specifications indicated thai ii would bean 
ideal 111 as an encapsulated measurement server. 

The base systejn would consist ofa SWiiHaCPU, -i2M bytes 
Of RAM and a 525-Mbyte hard drive. The system would be 



shipped from HPs workstation manufacttuing operation to 
the Colorado Springs Division, where a new < >perating system 
and the application code would he loaded and tested The 
completed product would be slopped to customers from 

_ ls a tumk . Xlininiizing the extra 

handling helped keep direct manufacturing expenses low. As 
with any new product, initial Inventory was difficult 
mate because there was no order history. However, the abil- 
ity to order and receive senticoruigured systems with fairly 
short lead times helped maintain a Sow inventory and thus 
contributed to a low manufacturing cost, 

-\ of sales Is defined here as the effort put into customer 
contact, demonstration, and objection handling during lite 
sales process. Although precise numbers on these efforts 
are not available, the design team had sufficient practical 
experience to know what factors contributed to a complex 
product and a higher cost of sales. 

Traditional itistrumenLs generally have a low cos! of sales 
because they can be easily explained, demonstrated, and left 
with the customer for an extended evaluation. The instru- 
ment model was used as a goal for prototype analyzer struc- 
ture, connection, and demonstration. 

A learning products engineer was assigned to evaluate barri- 
ers to installation and first measurement. Two goals weir 
adopted. The first was that customers should be able to £et 
the system running from a shipping box in less than one hour. 
This was accomplished by examining in detail the steps a 
customer would take getting from the shipping box m 
pow T er-up. 

A second goal of getting from turning on the power to a 
measurement in less than 16 minutes resulted in significant 
changes to the initial user interface design. The initial inter- 
lace used the standard window bar to access instrument, 

anaJysiSj and display tools After several days of usability 
testing ai a customer site, the learning products engineer 

mot ked tip a toolbox on Ihe I eh side of rhe workspace using 
masking tape on the monitor. The toolbox contained all avail- 
able tools. These tools could be dragged and dropped onto 
the workspace £see Rgi 3) and would automaticaU) conned 

themselves. 

The efforts put into these goals paid off. Both sales engineers 
mid customers round the producl easy to set up and run. 
The toolbox proved to he a big it it during customer demon- 
strations and added significantly to the ease of use of the 

product. 

Products with a substantial software content present sup 
port problems. The EDA industry generally addresses this 
issue with software maintenance or support contracts, 

w hich provide the customer with software updates and 
defed fixes over a specified period Of time Software main 
tenanee contracts are i»euerall\ prircd at a percentage of the 
total system software cost. 

The prototype analyzer team wanted to hold Io the inslru 
nteni model fcfosl Instruments do nc4 have software rnalrtft 

nance contracts. Instead, software upgrades and defect 

fixes are usually distributed through an ad hoc process of 
sales ;ijid system engineers personally distributing flexible 
his or occasional mailers to customers who have expressed 
an interest in future software upgrade 
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Fig. 3. Tools can be dragge* I I V, g i , 
the toolbox aj the left r- i M ■ ' ■ ■ I the 
iiisphy and dropped Gftfcd t&e 
workspace of the HE 1 L6S0SA 
] ii'i ii i jtype analyzer They Connect 
themselves automatic ;i ll\ 



The prototype analyzer I earn decided to implement a soft- 
ware notification process, This process would reduce the 
burden on the HP sales or system engineer of distributing 
new software and defect fixes- Delects and minor revisions 
would he distributed free of charge. Customers would re- 
ceive notification of the availability of major i e\ isiotis and 
related new products. 

The difficulty with this approach lay in the need for many 
new processes within HP. These included development of a 
call-handling center to interface with customers and get 
their names and shipping addresses for I he free updates. 
Process improvements are ongoing, but customers have 
indicated then- satisfaction with the approach, 

Standard Interfaces 

Somebody once commented that the great thing about stan- 
dards is that there are so many to choose from. The proto- 
type analyzer design team faced a bewildering array of net- 
working* data, and tool chain standards. Narrowing the 
choices down ro just a few supported standards would be 
required to meet the project schedule. 

N el working standards were quickly defined as a result of 
the decision to go with the encapsulated architecture. This 
choice necessitated the use of the X Window protocol to 
support local and remote control and FTP/NFS to get data in 
and out. of the system. Ethernet was the natural choice for a 



network connection. Fortunately all of the networking hard- 
ware and software was already present in the HP Series 712 
workstation and only needed to be augmented with a graphi- 
cal user interface. 

Early prototype analyzer users found thai I lie networking 
was sufficient but not ideal. In particular, customers asked 
for the ability to call up remote X Windows app Ileal tons 
onto the prototype analyzer's local display. This feature was 
useful because customers could access a remote application 
such as a schematic or text editor from the lab bench. This 
capability was added in a subsequent release of the product. 

Interfaces to hardware and software tool chains continue to 
evolve. The encapsulated measurement server approach en- 
ables the design team to maintain control over the type and 
maimer of data exchanged with other design tools. Having 
control over tins process provides additional robustness and 
stability which is critical to maintaining the low cost of sales 
discussed above 

The Results 

The HP 16505A prototype analyzer has met its price and 
performance goals. The only true measure of a product's 
contribution, however, is customer acceptance. A wide 
range of customers, including all major computer manufac- 
turers, have purchased prototype analyzers to aid in the 
development of their high-performance digital systems. 
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Measurement throughput continues to improve as the design 
team gains knowledge about the cause of performance bottle- 
necks. The ability to focus on a single platform and the sim- 
ple software update process afforded by the encapsulated 
nature of the prototype analyzer make it easy for the design 

! to develop and distribute new software that contains 
P< sfonnance i mprovements, 

Adherence to network standards such as FTP. \'FS, and the 
X Wii tem has towered the support burden. How- 

ever, the diversity of customer networking schemes does 
create a demand for foctory-based network trtHibieshocM 

expertise. The design team will continue to apply best net- 
working practices to the system in an effort to reduce the 
occurrence of network setup problems. I "sability testing will 
>ed to gain insight into networking problems. 

The ability of the architecture to suppon additional fum-i ji >u- 
cdir\ J makes it a conierstone of HP's real-time measurement 
solutioM for digital design teams. The reduced cost of incre- 
mental development and the low COS* <if sales and support 
are imj Ktffattt product attributes that outweigh the higher 
cost of goods sold compared to host-based architectures. 

Conclusions 

The development of the HP |ti505A pmtoiype analyzer pre- 
sented unique challenges to iiu* project team. The encapsu- 
lated itieMMiiHiNt'iif server approach taken by the team 
meant there were no guideposts to follow. The success of 
the project was in doubt until the product was introduced. 

The decisions described in this article maj appear obvious 
in hindsight They were not. The design team wrestled with 
the pros and cons of the measurement server ardntectoe 
t leeision U trougiio U i i h e pro di ic t de velopm en I < ■ > < I « ■ . \ s 1 1 v w 
data became available, the team eveniually rallied around 
the encapsulated approach. As with any new endeavor, at 
the time the decisions must be made, there are no right 
answers, only informed judgments. 

Tin design (rani learned severa] lessons during the develop 
i in hi process, One clear lesson vvas to Focus on solving nis- 
i oiuer needs Issues such as Internal architecture and form 
fart or ;.uv important, but clearly secondary to the problems 
the product is trying to solve. An important market research 



lesson the team learned is to encourage customers to de- 
scribe their problems, not their thoughts on instrument 
architecture- 
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A Normalized Data Library for 
Prototype Analysis 



The goal was that each analysis and display tool to be included in the 
prototype analyzer should be designed and written only once, Therefore, 
the data library is designed to normalize the variety of basic logic analyzer 
data types and the variety of postacquisition data types generated by 
various analysis tools and to present this data to other analysis and 
display tools in a standard format. 

by Mark P, Schnaible 



Karly in iho design of the IIP 16505A prototype analyzer we 
utilized we needed a new Library for storing and retrieving 
[Ogle analyzer data if we w T ere going to meet our project 
goaLs* We needed to duplicate the results of hundreds of 
software engineer-years of ef fori in the UP IH500A/B logic 
analysis system and measurement modules. We also had to 
lay the gnmndwurk to meet the requirements of our proto- 
type analyzer vision. 

Untie rs land ably, we did not want to allocate enough people 
to meet the first challenge for the duration of our relatively 
short schedule. However. looking at where the original lime 
was sjn'ui led to some insights, hi the original IIP UffiOOA/B 
system, effort bad to be duplicated for each logic analyzer 
plug-in raid introduced. That is, for each card, The 1 lister, 
waveform, chart, and other software modules needed to he 
rewritten. Some Code leveraging took plnce f but we did not 
come close to complete code reuse. The different ways in 
which the analyzer cards present data to the software (largely 
because of differing memory layouts) had much to do with 
tins lack of reuse. Out of this observation came the design 
goal I hat each analysis and display tool to be included in the 
prototype analyzer should be designed and written only once. 
This meant thai <mr library needed to handle I ho varirU m| 
basic logic analyzer data types as well as accommodate the 
variety of postacquisition data types that our envisioned 
analysis tools w r ould generate, and present this data to other 
analysis and display tools in a normalized format. Fig. 1 
shows the reduction in the dimensions of the coding effort 
we hoped to attain because of this library. It also shows that 
we would have automatic commonality of feat ure sets 
across acmiisit ion modules. Previously, some features for a 
new logic analyzer card were nut present ht the initial release 
of that card. 

Several other design goals emerged thai would allow us to 
meet our challenges; 

Retrieval time for analysis and display tools to access the 
data should be minimized. In the HP IfiSOOA/B environment, 
the acquired data is examined in typically one display per 
acquisition. In the prototype analyzer environment, the goal 
was to encourage data exploration and to view and analyze 
acquisitions with several tools. We wanted to permit users 



to examine data simultaneously with the same view in dif- 
ferent locations and with different views in the same loca- 
tion. These use models led to multiple accesses of the same 
data, in contrast with the HP h^>00A/R model of a single 
view 7 of data in a single location Pig. 2 shows the equivalent 
prototype analyzer graph of an MP UoOOA/B use model w r hile 
Fig, 3 shows a prototype analyzer graph with the multiple- 
view, multiple- location use model. 

Acquisition 



Modules 




Analysis and Display Tools 




HP 16517A 


Waveform 


Lilting 


Chan 


Distribution 


HP16532A 




HPT6550A 


Waveform 


Lis ling 


Chart 


Distribution 


HPfG555A 


Waveform 


Listing 


Chan 


Distribution 



|a) 



Acquisition Modules 




HP 1E517A Data Driver 




,--"' 


HP 16532A Data Driver 


I* 

— H 

— n 


Norma lira) 
Data 




HP I6550A Data Driver 




HP 16555A Data Driver 


1 w 







Analysis an if Display Tools 



Pattern Filter 



Performance Analysis 



Software Analysis 



Fig. I. u;i hi the HP L05O0A/B logte analysis system coding 
tool software had EC be rewritten for each | lug-it i eajsL (10 In tho 
HP L65Q5A prototype analyser coding model, data is norn 
immediately after acquisition and is available to aJ3 tools iti a stan- 
dard format. Thus> the tools had to be coded onlv once. 
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Fig. 2, PrcH zer graph 

of an HP 16600A/B logj 

lise m 



StOTage space for acquired data should be minimized. Given 
the potential size erf some logic analyzer aequisil h HIS 

'M bytes), undue expansion of the data w;ls unaccept- 
able. As always, however, there exists the trade-off between 
minimized retrieval Time and minimized storage spare. 
• The storage mechanisms used by the library should be com- 
pletely decoupled from application or client modules. That 
is. changing the way data is stored should not affect any 
lines of client code. Examples of client code include the 
tools that analyze and display the acquisition data such as 
the lister, waveform, chart, distribution, and pattern filler 
tools. 

Tin- interface to the library should hea ,t naturarc+<f-siyir 
application programming interface. No new style of pro- 
gramming should he introduced ihat would bedifterenl 
from norma] C++ syntax. 



• The library should provide a layer of memory management 
aver (he acquired data. Again, the possibility of 'very large 
data sets makes it vitally important not to leak these huge 
memory chunks or provide stale pointers to nonexistent 
data. This goal is made more difficult by the potential com- 
plexity of graphs possible in the prototype analyzer. Fig. 3 
shows that there may he many analysis and display tools 
examining and viewing the data simultaneously, All of these 

references i<> the data nausl be handled property to prevent 
large memory leaks. 

* Finally, time correlation between different sets of data or 
analyzer acquisitions must be possible. This requirement 
makesi M possible foi users to exaimne their systems on 
several different hierarchical levels concurrently, from look- 
ing al Ihe analug naliin' r>l ;i ground pin bouncing tO Junking 

at the high-level source code executing al that moment m 




Fig, 3. PrototypH i ml. ■■ i i 
,in in 1 L6505A prototj i" " 
multiple vM-u, multiple location usr 
model, 
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time. Time correlation of measurements also makes it feasi- 
ble to plot one derived measurement against another derived 
measurement. Previously nonobvious relationships between 
variables may appear as a result of these charts. Simply 
having the ability to move markers in one view of an acqui- 
sition and watch that location automatically tracked in a 
different view of the same acquisition is another benefit of 
tune correlation. 

Starting with this list of requirements, we searched for any 
existing libraries that would meet our needs. We examined 
three HP interim] libraries and one public-domain library 
None of these met all of our requirements. Among the rea- 
sons we rejected them were data set size limitations, 
non-C++ APIs, file-based memory storage, inefficient stor- 
age models, inability to handle the variety of datatypes, and 
mismatches between application models. 

Data Sets and Data Groups 

The visual programming user interface of the HP 1650 5A 
prototype analyzer presents users with a I eft- to- right flow of 
data from sources to displays. Lines between the icons rep- 
resent this flow. The first thing to decide was exactly what 
kind of objects move from icon to icon. 

One of the first things users do in the HP 16500A/B environ- 
ment; is to define what the analyzer probes are connected to. 
This seemed like a natural place to start our definition of the 
normalised data library. A label entry represents one or 
more probes defining a logical value. Typical examples are 
the logic analyzer probes connected to an address, data, or 
status bus of a microprocessor or an oscilloscope probe 
connected to V cc> V SS) or a clock signal The label entry has a 
name, polymorphic ordinal e data, attributes, and perhaps a 
database of value-to-symbol mappings associated with it. 
Pig, 4 shows the class diagram of a label entry using the 
Booch notation. 1 A logic analyzer or oscilloscope commonly 
probes several of these label entries. 

If we collect all label entries that share exactly the same 
sampling information, we have a data set. All of the label 
entries from a single logic analyzer acquisition share the 
same sampling information, so they can be collected into 
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Fig. 4. Ctea diagram of the label entry class using Booch notation, 1 

a data set, Likewise, all of the label entries from a single 
oscilloscope acquisition share the same sampling informa- 
tion. The data set contains a pointer to some polymorphic 
data representing (his sampling or x-axis information, We 
call this the abscissa data. The actual abscissa data object 
varies with the type of acquisition. The data set also contains 
i i i i i v. co rre I at i on information ind i eating wh i c h o 1 1 1 e r d at a 
sets a particular data set can correlate with and indicating 
their relative trigger times. Another form <>l information 
contained in a data set is called tags. Tags represent the 
availability of each sample row in a data set. Tools such as 
the pattern filter oi the sequencing filler can remove lines 
from a data set based on some pattern of data or a sequence 
of data. The memory for these lines is not deleted; the lines 
are simply marked as not available by these tools. 

When we collect one or more data sets for input to a tool, 
we have a data group. Data grotips are the objects that "go 
along the wires" of the visual programming graph. A data 
group is simply a list of data sets and some information indi- 
cating 1 he nature of correlation among the data sets. A data 
group may contain data sets that have no correlation, time 
correlation, state correlation, or both time and state correla- 
tion. Each tooi can indicate to the system what kind of cor- 
relation it requires incoming data sets to have. Inputs that 
do not match this criterion cause a warning message to be 
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Fig. 5. Sags diagram for data sets 

and data groups. 
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Abscissa Data 



Time Tags Periodic 



Fig. 6. i 'hiss hierarchy for abscissa data, 

sh< >w n on ihe display, Fig. 5 shows the class diagram for 
4 lata sets and data groups. 

Abscissa Data 

As mentioned above, the X-axis information (the abscissa 
data object contained within each data set ) is a polymorphic 
type dependent on the type or acquisition or measurement 
of the data Fig. 6 shows the class hierarchy of this informa- 
tion The abscissa daia base class represents a simple num- 
bered sequence of states with one of those states being the 
Trigger state. This concrete base class is the type used for 
generic logic analyzer state clocked acquisitions with no time 
information, that is, no time tags. Objects of type periodic 
arc used for logic analyzer timing acquisitions as well as 
oscilloscope acquisitions. This class stores information 
about the sample period and exact time at trigger, The time 
tags class is used for logic analyzer stale acquisitions with 
time tagging turned on. These lags indicate the exact time 
for each sample, which may or may nut be periodic. This 
class is also used for calculated data sets derived from logic 
analyzer acquisitions. For instance, a series of setup and 
hold calculations derived from a timing acquisition will have 
a lime tag for each pair of setup and hold values. We can 
s;ive considerable space with this technique because the 
sen if > and hold times are sparse compared to the sample 
density of the original acquisition. 

Ordinate Data 

The probed data car calculated data contained in the label 
entries is also a polymorphic object. The base class of this 
hierarchy is an abstract base class called ordinate data 
which defines the interface for classes derived from ordinate 
data. Fig. 7 shows the class hierarchy rooted with ordinate 
data. Classes derived from ordinate data are analog, sfa 
glitch, and staff count Other classes can be added l u this 
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hierarchy as needed, The analog class contains a polymor- 
phic pointer to the quantized samples and an object specify- 
ing how to convert these quantized values to floating-point 
values. In the case of an oscilloscope acquisition, this 
header contains the formula to convert from quantized sam- 

rc> voltage. The state SS i ontains a pointer to some 
polymorphic data representing the binary values acquired at 
the logic analyzer probes. The glitch class contains the same 
information as the states class as well as a parallel data ob- 
ject indicating the presence of glitches for each sample. The 
HP o t*ic analyzer card is capable of acquiring this 

type of data. The state count class holds the data represent- 
ing rhe number of states that transpired between acquired or 
store-qualified states. The trigger systems of HP logic ana- 
lyzers allow users to specify which states to store out of all 
the states the logic analyzer sees based on some sequence of 
events. The state count object holds values that represent 
the number of states that were not stored 

Analyzer Memory Layout 

Our definition of a label entry shows that the data for each 
label entry is stored with that label and the data for no other 
label entry is stored with that label This contrasts with the 
HP 16500A/B series of logic analyzer cards in which all of the 
acquisition data is stored in one block of RAM- Each time 
the data for a particular label needs to be retrieved, the bits 
must be extracted from this block and packed into a value 
representing a sample. As Figs, 8 to 10 show, the format of 
these blocks of memory differs from analyzer to analyze r J 
The data formats in the acquisition cards are designed to b< j 
optimally space-efficient. There is a one-toone mapping 
between bits of memory and probe tips so no memory waste 
occurs. There are two downsides to this design choice: 
ilit ime must be spent every time a sample needs to be ex- 
tracted from this block of memory and (2) the memory lay- 
outs are different for each analyzer. For the multiple-view, 
multiple-location use mode] of the prototype analyzer, access 
time for each sample of data ^ critical For eode reuse rea- 
sons, we need tohide the memory layouts from client code. 
Since these acquisition cards were already in production, we 
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had little i n < > i i \ ; 1 1 i o n to all 1 t th 6 way they presented data t < > 

the prototype analyser. We wanted to minimize I he- soil ware 
investment in these finished products, 

Format Specifications for Labels 

Fig. 11 shows a partial formal specification for the Intel P54C 
microprocessor. Customers use this dialog to specify which 
pins on various pods of logic analyzer proxies are connected 
to different labels. Some labels, such as for an address bus or 
a data bus, lend to be probed with contiguous probe tips. 
However other labels can be probed with discontinuous pins 
from different pods. The exception label (Excptn) in Fig. 11 is 
an example of this in ihe P54C specification. Depending on 
the complexity Of the formal specification, the extraction 
time for these labels can vary greatly. Even for contiguous 
labels with widths of 32 or H> bits sucb as address or data, 
considerable time can be spent extracting these values from 
the monolithic block of memory. 

For the normalized data library, we decided to extra <i the 
data for each label once for each acquisition and store if in 
its own chunk of memory, babel entries whose bit widths 
match the native machine data type widths (8, 16, or 32 bits) 
are extracted and stored as arrays of C++-type chars, shorts, 
or ints. Once these samples have been extracted or normal- 
izetL subsequent retrievals are simply array lookups. All 
labels that have non-native widths are combined into a block 
of byres. Before the values are inserted into this block, how- 
ever, any discontinuity in the ordering of the bits is removed 
to speed later retrievals. Some Space inefficiency can result 
from this technique. The total possible bit wastage is: 
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32 Biis 




tCBits 



Sfl SI S2 S3 S4 S5 S6 57 



\1 Clank Bits per Sample) 



(Twd Acquisition 

Chips per Cnrd; 

n'= 1 lo IDj 



Sa 59 SID S11 ST2 S13 SH SIS 



Fitf. 10, HP 16555A n uuired data formal ( hilt -channel mode only). 



We make this trade-off to provide faster access times to the 
data. Data drivers for each Logic analyzer module supported 
are responsible for normalizing the data. These drivers can 
be arbitrary about choosing data types because they know 
the memory layouts of the cards and the specific widths of 
labels. Fig. 12 shows the class diagram of the ordinate da la 
types with the various integral data types. 

Accessing the Data 

Once we have sloivd the data in a normalized format, we 
need methods to access the daia. A study of existing code 
and an analysis of how future tools mighl need to access the 
data showed that retrieval tended to be very sequential in 
nature. If we picture an acquisition as a matrix of data, with 
row r s representing samples or time and columns representing 
the various labels, two retrieval styles emerge: row major 
and column major. Tools that use the row major style want 
to examine ail of the labels for a certain sample before they 
proceed to the next sample. The lister, pattern filter, and 
sequencing filler use this style. Tools that use the column 
major style look at all samples of a particular label or column 
before they look at the next label. Waveform drawing, chart- 
ing, and hislogiamming tools access The data I his way. 

A programming idiom that supports this sequential nature of 
accessing data is called an iterator; 1 We defined classes for 
iterating over data contained in the abscissa data class hier- 
archy as well as data contained in the ordinate daia class 
luerarchv Fig. t$ shows the absdssa-itor class hierarchy 
and Fig. 14 shows the ordlnate-itor class hierarchy. 

Boih diagrams show that there is a one-to-one correspon- 
dence between data types and Iterators over those data 
types. Since we don't want client code to know how r he daia 
Is stored, w r e need some way to hi fie this information from 
clients while still providing them with a way to get at the 
data. We use the letter/envelope programming idiom to 
accomplish this. } Clients construct an envelope object (jfiFfiffc- 
eral abscissa-Uo-r and general ont///>itt--/{orm the diagram), 
which can then ask the data to construct an iterator over 
i I self Clients never have to know 7 what kind of data is being 
accessed. The envelope and letters are derived from a com- 
mon base class which defines the interface for the iterators* 
The envelope Serves as a forwarding ubjeei lu the real itera- 
tor, the letter. The iterators have an orthogonal interface for 
data retrieval and iterator positioning. There are methods for 
looking at the next mid previous data elements (which then 
alter the position of the iterator), methods for pecking at the 
next and previous data elements (do not alteT the posit 'a m i. 
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Fig. II. Partial .format specification 

t\ .j r 1 1 i< ;i I nt e I P54 < essor. 



methods for querying and setting the position of die iterator, 
and methods for testing forward and backward iterator 
exhaustion. Multiple iterators can be constructed to look at 
the same data; litis would be the case in a prototype analyzer 
graph that takes advantage of the multiple-view, multiple 
location use model Iterators are declared so thai Ihey can 
only access the data. We provided no iterator methods that 
would modify the data. 

Wi also defined an inramr that is a combination tot an 
abscissa-ilor and an onlinate-ifor. Thr rfuta-itnr rririt'vcs 
pairs of values ivpivsrniing the value ol a label and the sam- 
ple or time at which it occurred. In addition to the orthogonal 



interface described above, this iterator also pr oxides methods 
to report the value and location of the next or previous 
change in the ordinate data. These, met hods are useful for 
waveform drawing algo rith n i s . 

Row major iteration over multiple correlated data sets is 
aided by group abscissa iterators. These iterators examine a 
list of abscissa-i tors (one for each data set in the data group} 
and return the next or previous x-axis value and a list of 
Identifiers t I mi selecl the data sets from which that value 
Comes, These iteralors come in handy, for example, in visual 
programming graphs ihat have multiple analyzers fanning in 
to a Single analysis tool (Fig. 15). For a lister display that has 
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mulliple data sets merged (Fig. 16), we need to show the 
data from lhe various analyzers interleaved in nine as they 
were actually sampled. 

Memory Manage me nt 

Willi the increasing nrquishion depth and width of HP Logic 
analyzers, data sets (an have sizes greater than 40M bytes. 
In the prototype analyzer environment, users can be examin- 
ing these data sets in several locations with several views. 
Having so many references to the data can easily lead to 
memory management problems, particularly nasty among 
them being memory leaks and pointers to si ale memory 
A memory leak occurs when a process no longer has any 
references to a chunk Of memory I hat has been allocated 
in nil iht j hea}i nl memory available to the process, and tin is 
there is no way to return the memory back to the heap. As 
an application leaks more and more memory, less is available 
to that process and eventually the application will halt be- 
cause of an out-of-memory error, leaking very large blocks 
of memory will cause this condition to occur sooner. Pointers 
to stale memory result when the application does return a 



Fig. 14* I >]vini,iii-iii'r class liii-njrHiv 

chunk of memory to the heap but keeps other pointers to 
that same memory; which the application no longer owns. 

Tl ic norm al i zed d ata lib rary uses the r ef ere nee counting 
idiom 13 to overcome these potential problems. Passing a data 
group from one tool to the next creates a copy of the data 
group. These copies result in incrementing reference counts 
lo live individual blocks of data contained in 1 lie abscissa data 
and ordinate data object hierarchies. Defining an iterator 
over this data also constructs a copy of the data, which 
causes a reference count increase, Destroying the data 
(by deleting a tool) or deleting iterators causes these copies 
to be deleted, whit -h then causes the reference counts lo be 
decremented. When the reference counts reach zero it. is 
safe to release the memory back to the heap. At I hat time we 
are sure no other references to that memory exist The nor- 
mal execution of a tool includes these steps; 

• Delete the old output data group o(' Hie tool 

* Delete the old input data group of die Tool. 

{ 'unstrucl a new input data group for the tool by merging nil 

inputs 

Execute The tool (delete old iterators and construct new 

ones). 




Fig, 15, A visual programming 
jp&ph v\ irl i mulTifjli' muilyzers 
fanning in to a single an 
tool. 
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» Construct a new output data group for the tool 

\Vi' defined our iterators such that they do not modify the 
underlying reference con mod data In cases where tools need 
lo modify the reference counted data (such as pattern filters 
which modify the tags object in a data set i we use fho copy- 
on- write optimization: operations thai would change the 
data cause a completely new Copy of the data to he created 
and cause reference ennuis fo tic adjusted accordingly. 

Case Study 

During the design of the normalized data library fur the 
prototype analyzer we made a conscious decision to incur 
the overhead of normalizing the acquisition data immediately 
after transferring the data From the MP L6500B mainframe to 
the prototype analyzer This happens once per acquisition 
and before any loots examine the data. We do this immedi- 
niely tO i optimize the response time of post acquisition data 
exploration. For very huge acquisitions, however, this 001 s - 
mnhzahon time can he considerable. 

At the initial release of the prototype analyzer, one customer 
was making such an acquisition with 1M byte deep HP 
L6556A ir.ojr analyzer cards probing an Intel F6 mieropro- 

cessoi and a PCI bus We found The normalization tiiur to lie 
too large in this ease — the acquisition data exceeded 30M 
bytes. After studying where our code was spending time 
during the normalization process, we optimized certain 

sections of code as well as significantly changed the way in 

Which the daia driver lor thai module stored the data in Ihe 



Fig. 16. A lister display willi 
multiple data sets fanned it i 
The Jala sets frqjfl 'In prions 
analyzers are interleaved in time 
as 1 hey were actually acquired. 



object hierarchies. After our optimizations, we reduced the 
normalization lime by a factor of ten. More important, we 
did noi need to change a single tine of client code (lister, 
waveform, chart, etc.) to take advantage of this optimizain m. 

Conclusions 

At the introduction of the HP L6605A prototype analyzer we 
met most of our project goals. We duplicated almost all of 
the IIP lu50QB funclionality for the HP i65- r >0/4/5/t)A. UP 
16517A. and MP L6532/3/4A acquisition cards and added se\ 
end significant lealures such as partem filtering and multi- 
ple- view, multiple-location data exploration. The ability to 
write a single dynamically loaded shared library lor each 
analysis and display tool that would work for any of the data 
retrieved from the acquisition cards w T as prominent among 
the reasons we met our goals. We continue to create new 
analysis and display tools that will help our customers solve 
their most difficult design problems. 
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A Full-Featured Pentium- PCI-Based 
Notebook Computer 

The HP OmniBook 5000 computer takes advantage of new technologies 
such as mobile Pentium, PCL plug and play, lithium-ion batteries, and hot 
docking to give users the same capabilities as their desktop computers. 

by Timothy F. Myers 



The HP OnuiiBook 5000 computer (Fig. 1} marks a change 
in the direction of notebook computers designed by Hewlett 
Packard, Earlier OnniiBook products focused on being 
ancillary tools to the conventional desktop PC. Hie designs 
were biased towards small size, long battery life (or more 
usually, a smaller battery), and the ability to run most major 
programs. They brought to die customer new features such 
as histant-on s battery charging wiiile operating, expandability 
via the PCMCIA standard (now known as PC Card Standard, 
or more simply P< ' ( Sard), and Simplified use. As customers 
became acquainted with their mobile computers they de- 
manded that their portables have the same functionality as 
their desktops. Thus began the emergence of color displays, 
larger hard drives, faster processors, and external flexible 
disk drives in the IIP OmniBook family. When die Corvalhs 
Division became the Mobile Computing Division with the 
charter to design, produce, and market a full range of mo- 
bile computers, we realized thai we needed to fill a gap in 
HP's computer line: the full-featured notebook computer. 

Full-featured notebook computers today are characterized 
as having the same 1 capabilities as desktop computers, albeit 
with some time lag for the highest performing models. Over 
the past few years, the spread in processing performance and 
features between notebooks and desktops has narrowed. At 




Fig, l. HPOmniBool iputer, 



the end of LQ9&, the gap was only about three to six months. 
Todays customers not only demand thai their notebook 
have the same capabilities as their desktop but also expert 
more m features that make mobile computing easy In addi- 
tion to being a desktop replacement the notebook computer 
should provide the same flexibility in prepurchase configu- 
rations and future expandability. 

lb facilitate HP's entry into the full-featured notebook mar- 
ket we chose to partH6T With a foreign notebook design and 
manufacturing company to quickly modify and produce a 
prod net for this segment. While the HP OmniBook 4000 was 
a very solid and feature-rich notebook product, our custom- 
ers quickly requested features that were unique to our origi- 
nal OniniBooks, especially instant-on. Instant-on is a feature 
that allows users to put the machine into a low-power state 
and later resume working exactly where they had suspended 
their work The main difference between HPs instant-on 
and our competitors' suspend feature is that the amount of 
time that our products can remain in the suspended state is 
measured in weeks, compared with hours or a couple of 
days for competitors. With the advent of new" technologies 
such as mobile Pentium, PCI, plug and play, lithium ion bat- 
teries, and hot. docking, we felt, that we could design a prod- 
licI that would set HP apart from many competitors offering 
Pentium notebooks. The HP OmniBook 5000 shows that 
there are still abundant areas for contribul i* m, even in a 
highly competitive market 

Because of the multiple choices before us in chipset selection 
and peripheral !< ' technologies, we need&j to have >i>me 
major goals to guide our design process. While earlier HP 
OniniBooks focused primarily on size, power, compatibility, 
and performance, in that order, our criteria were different. 
Our target market was to be mainly corporate users, so our 
first goal was compatibility: a If we can't run it, they won't 
buy it." If our product makes it difficult to get some program 
or utility working, our customers will pick another product. 
The second major goal was performance. If our product is 
not near the lop in benchmark performance, we will not 
appear to be technology leaders. The third goal was power 
management. If our pr« »<iiu i does not run very long on a 
battery charge it will not be very convenient. If we do not 
manage power wisely, the hear generated by the compo- 
nents could affect reliability nmctionaiiiy. and customer 
satisfaction. Of course, there were other goals, such as con- 
venience, quality, reliability and functionality. However, the 
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first three guided the decision process for the HP i imniBook 

soon 

Architect tire 

The HP i HanSta >k BOQOfe architecture is based on a layered 
bus concept Pig. 2 is a block diagram of the computer This 
approach allows the devices thai need higher data hand- 
widths to reside on an appropriate layer to maximize perfor- 
mance, power, number of pins, and ft nationality. The widest 
bandwidth bus is the Pentiums 64-bit data hus. On this bus 
are the system I >RAM memory, the lcvel-2 cache, the host 
bridge, and the Pentium CPU, Tlie GPU bus can operate at 
50, 60, or 66 MHz, depending on the CPU processing speed- 
Ins imperative that externa! memory data be delivered to 
the CPU as fast as possible. The Pentium processor has UiK 
bytes (8K data, SK code) of internal level- 1 cache, and the 
CPU module can support 256 K bytes of external lcvel-2 
cache* The leveI-2 cache is implemented using burst 



synchronous static RAM with fast access speeds so there 
are no wafc flier than the address lead-off cycle. 

Because the Pentium CPl and le\vl-2 cache consume quite 
a bit of power evpn in a nonelocked state, the power to 
these devices is turned off during suspend periods and the 
control signals from the host bridge are put into a high-im- 
pedance state I tristaled l The host bridge provides the 
DRAM aw I »nirol and also serves as a gateway to 

the PCI bus. 

The system DRAM can be arranged into four logical banks 
in two physical slots. The user can select from 3M to 6419 
bytes of memory m granularity of 8, 16, 24, >2. 40, 48, and 
64M bytes by rumbiniiig SM-hyte, l6M-byte. and 4I\\-\ 
modules- The DRAM supports self-refreshing, so when the 
HP OmniBook 5000 is suspended, the DRAM retains its con- 
tents without docks or signals from the host bridge. All 
DRAM memory is removable and accessible which makes it 
easier to replace and Upgrade, 
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PCI-Based I/O Architecture 

Tlit* HP OmniBook 5000 I/O bus architecture is designed 
around the Peripheral Components Interconnect (PCI) bus. 
The PCI bus in the HP OmniBook 5000 is designed to run at 
33 MHz for all processor speeds. At 32 bits of data width, the 
theoretical bus transfer rate at burst speeds is 132 Mbytes 
per second. This overabundance of data transfer bandwidth 
allowed us to add many devices to the PCI bus to increase 
system performance. The video, SCSI, and 16-bit PC Card 
(formerly PCMCIA) controllers all reside on (lie PCI bus 
along with the CPU host bridge and the ISA (Industry Stan- 
dard Are hi tec tu re) bridge. The SCSI controller, the CPU host 
bridge, and i be ISA bridge are capable of bus mastering, 
which ;il lows them to assume control of the PCI bus. 

The PCI-to-ISA bridge contains the power management unit 
that controls the CPU clocking and peripheral power states. 
The ISA bridge also contains the standard PC-compatible 
components such as the interrupt controller, the DMA con- 
troller, system timers, memory mappers, and the ISA bus 
interface. This IC translates the 32 -bit PCI bus commands 
and data that are directed to the 16-bit ISA Bus, 

The CPU clocks are managed by using a clock throttling 
scheme. This method was developed for the Pentium CPU 
since it has an interna] fractional frequency multiplier to 
allow higher processor speeds while limiting the external 
bus speed Because of this multiplier function, one raimul 
just slow down the CPU's frequency to reduce power con- 
sumption as was done in previous products. Instead, the 
power unit makes a request to the CPU for permission to 
stop the clock. The CPU responds by issuing a special bus 
cycle when il is finished with the current instruction and 
then stops its internal (lock. When an external event such as 
an I/O or timer interrupt occurs, the power unit releases the 
request signal and the CPU restarts its internal clock and 
resumes operation. Fig. 3 shows the timing of the stop -clock 
function. 

The ISA bridge includes a 32-bit IDE controller, which allows 
faster disk accesses with newer operating systems. This IC 
redefines the ISA bus during idle cycles to handle the 16-bit 
IDE hard drive com roller signals. Buffers provide isolation 
between the IDE and ISA buses and allow the hard disk to 
be powered off while the system continues to function. 

Video Controller, The IIP OnuuBook 5000 video controller 
features LCD panel (DSTN or TFT) and external video inter- 
faces with VGA or SVGA options. In addition, the video sys- 
tem provides NTSC/PAL video output (the video used in 



V( -lis or camcorders) to allow presentations to be displayed 
on a siai idard TV monitor or recorded on a VCR for playback 
at a later date. 

Tire video controller resides on the PCI bus so that data from 
the CPU is quickly written to the video memory. The video 
memory provides a IM-byte video space for up to 6 -I million 
colors in 640 x 480 VGA mode, It also has a 0,5M-byte frame 
buffer to increase the performance of the dual-scan (DSTN) 
LCD. The memory on the video controller operates u\ 1:3V 
to conserve power and reduce beat. The video DRAM's self- 
refresh mode preserves the video screen data while the HP 
(mini Ho<«k 0Q0G is suspended and clocks to the video run 
troller are stopped 

The video circuits automatically detect when a user con- 
nects either SVGA or NTSC/PAL video cable to the HP Omni- 
Book 5000. The BIOS will detect the appropriate monitor 
type and enable the proper video settings base 1 1 on I lie 
selections made hi the system setup ulilily. This feature 
makes it easier for the user to set up presentations quickly 

IB-Bit PC Card Controller. The PC Card controller resides on 
the PCI bus to allow for several features. By making this 
controller a PCI device, we arc able to map it to a different 
I/O address should there be a conflict with a legacy ISA card 
in the docking station (described later). This design makes it 
possible to support new PC Card standards (eg, ( ardbus, 
based on 32-hit PCI) in the docking station by remapping or 
disabling the internal controller. We are also able to increase 
the system performance by having PC Card accesses bypass 
the bus translations that would be necessary with separate 
PCI, ISA, and PC Card buses as in the classical implementa- 
tion. Performance is also increased because devices that 
support DMA (e.g„ the sound card) do not slow down ( T! 
to-PC Card transfers (i.e., networks). The HP OmniBook 
5000 design has two slots for either two type II cards or one 
type III (double-height) card. The interface software allows 
the cards to be shut off completely during suspend mode 
and to be restored when operation resumes. Device drivers 
are designed to support advanced power management calls 
(described later) to prevent disk corruption during suspend 
mode. 

SCSI Controller. The SCSI controller option on the IIP Qrnni- 
Book 51300 is provided to give the user a simple way of con- 
necting to external devices such as CD-ROM, external hard 
disks, backup tape drives, and scanners. This versatile inter- 
face provides a high data transfer rate (up to 10 Mbytes per 
second). The SCSI interface can be disabled when not in use 
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to conserve power. A SCSI BIOS is provided so no drivers 

jinred bo OpeJ -I hard disk if ii is i 

when the system boots. This SCSI BIOS supports the SCAM 
protocol which allows The user lo >h the St SI II >s for S( A.M- 
equipped dev> he HP OmniBook 5000 keyboard to 

simplify setup 

SpeciaJ det i tpporl advanced 

power n read write operations to 

the disk from being interrupted when the user tries I 
into nd mode. Tliis feature helps prevent com. 

disk hnages resulting from mobile use, which was not taken 
into account when die SCSI standard was developed. 

Keyboard Controller 

The keyboard controller in the HP OmniBook 5000 provides 
the personality of the notebook. It performs many of the 
notebook-related tasks so that the Pentium CPU can remain 
focused on compatibility and performance. Some of the. 
i asks performed by the keyboard controller are: 
» Keyboard scanning 

• Support for three PS/2 ports (internal trackball, external 
mouse, external keyboard) 

• Status panel control 

■ Battery charging at id low-voltage iiioniToniiy 

« Battery capacity gauge communication and tutoring 

• Temperature sensing and thermal feedback control 

• Interface to EEPROM for passwords, PC 1 Tattoo, serial 
number, and Other system tunable parameters 

• Docking station control 
Powei on/off control. 

Because of the complexity of the tasks it has to perform, the 
keyboard controller is flash-memory-based so thai it can he 
rcprogrammed in the held along with the system BH >S and 
i he EEPR< )M that contains user and system tunable parame- 
ters for battery charging, voltage detection, and so on. A 
special technique was implemented to perform the in-cin nit 
programming of the Jlash memory in the keyboard controller 
First, a bootstrap program is downloaded lo the keyboard 
con I roller RAM Space and executed. Tins program lakes 
over the keyboard con I roller aw I handles the t omnnnm -at ion 
with the Pentium. The Pentium downloads the Bash update 

jam into the keyboard controller's RAM. The Hash 
memory inside the keyboard controller is erased and then 
the tk a keyboard controller BIOS is transferred to the key- 
board controller and programmed into the Rash merooi 
I pun a hard reset, the keyboard control!*! begins function 
ing wilh the neu I5K >S. 

The keyboard cont roller has ei gh I 3 - b i t a n a ! o g I m -d i g i I a I 
convener (AIM i channels, which are used lo monitor the 
haiiery temperature for each of the i wo battery stotSj ih< 
GPU temperature, theambienl temperature^ berth battery 
slot voltages, and a 2.6V reference. The voltages read by the 

Al h ' channHs an- digitally fillered la the keyboard c< ml roller 

before being use*! by the system Bins. 

The keyboard controller also bandies talking to various I/O 
ports such as three PS/2 channels, two Benchmark smart 
battery channels, and an l~r Interlace, Events thai i 
higher priorities are serviced first by die keyboard c-ontrolkt 
If i he keyboard controller is servicing a lower -priority task 
ami a higher-priority event occurs, ii is processed first and 



the lower-priority task is rescheduled. The highest-priority 
tasks are docking and low-battery detection, then keyboard 
and mouse-related tasks, followed by housekeeping chores 
of battery charging, battery capacity monitoring (see bet 
and status panel updating. 

Smart Batteries with Tutor Assist 
ICs in the IIP i >mniBook 54 slow the bat- 

ten i r charge state and status information 

If the ba! moved from ih<- HP < ImniBo and 

■■[■ c-harged in another device, the capacity of the bat- 
tery is reread from the pack when it is reinserted. These 

irtf batteries can measure their temperature and current 
How ami perform compensated updat ea of i he I iat t eiy * 
ity gauge so that, over time, the gauge contents do relied 
the state of the battery. 

Although there is quite a bit of intelligence designed into da- 
ily gauge circuits, there are events and bound- 

■in lit ions that result in the gauge's u< >t i ♦'presenting the 
Capacity of the battery accurately. One example is the first 
lime the battery pack is assembled The capacity gauge n - 
quires that the battery pack be discharged and then charged 
back to a full state to calibrate and initialize the bait cry 
capacity reference. So that the user does not have to per- 
form this function, the HP OmniBook 5000 will calibrate the 
pack under certain conditions when ii knows the batters % 
charged state. At those nines, the HP OmniBook 5000 will 
compare the pack's battery capacity reading and if it dis- 
agrees with the HP OmniBook 5000's own gauge by a iixii\ 
factor, the pack's gauge will be updated. This tutoring ap- 
proach provides a closed-loop system to help correct for any 
inaccuracies caused by component tolerances, bad assump- 
tions by the smart battery, current crest factor corrections, 
and charging inefficiencies. VViih ibis approach, the user 

not have lo be involved in the i. calibration of I he bat- 
tery pack. The philosophy is ibal. even with machines, two 
heads are better than one 

Power Supply and Battery Charging 

The power supply generates :J.:JV. 5.0V. and 12,0V. ll can 
charge either a \iMfh buttery using a eonsiani current 
source or a Li Ion Battery using a conslanl current/const an 1 
voltage source. The ac adapter is the same as that used by 
the IIP OmniBook 600 Series. It provides an output of 12V at 
3.3A maximum current or a total powei ofal r in watts. 

Half of the adapter wattage is used to operate the product 
and hal) Is used n> charge the batteries in the system. Tin 
ban cry voltages for both the NiMIh and Li-Ion packs can 
e&Ch be higher cjr lower than the + 12V adapter vc ullage, de- 
pending on the charge stale of tin' cells, A flyback configura- 
tion is used in lite adapter sine e ii can be deigned to Support 
1 1 lis i i i l, - f mi t(sn < "Flyback Charger Circuit 1 < m page 42 }. 
The power to the batteries during charging is limited by both 
current and voltage sensing. An important convenience goal 
of the IIP < HuniHook 5000 was to charge and operate at flu 
same time. This feature allows tin* user to operate the ]\]> 
OmniBook r,0im dminu '!■< da.\ and still have full battery 
power for ready use after disconnecting I he Computet from 

theac adapter* 

Thetf.tfV and 5.0V regulators use a synchronous switch ing 
topology I hal allows I lie power supply lo maintain a high 
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level of efficiency. The + 12V output is derived using a trans- 
former tap on the 3.3V inductor to generate about 14V, which 
is then linearly regulated back to + 12V This technique gen- 
erates a very clean and stable + 12V to program the system 
flash memory; the keyboard controller flash memory, and 
any PC Card memory cards. Sometimes the -f- 12V is used 
for analog circuits on PC Cards, so we felt it necessary to 
provide a filtered signal 

One challenging design parameter of The power supply is 
that it musi deliver about IFjW during maximum Operation 
and also maintain regulation while supplying less than 
I'.h i ni\Y u» the system in suspend mode. 

Docking Strategy 

The IIP OmniBook 5000 docking station (Fig. 4 ) provides Ihe 
docked computer with one PCI slot and 2 ISA slots, giving 
the user access to the same options as desktop users. The 
docking station provides one-handed, power-assist ed docking 
(VCR style). The I/O ports on the HP OmniBook SOOO are 
replicated on the docking station so thai the user 1 does not 
have to remake a lot of cable connections. Some ports, such 
as the sound system f line in, line out, and microphone), MIDI, 
and SVGA out ports, are passed straight through the docking 
srat ion. Other interfaces such as the SCSI, RS-232, parallel, 
and game ports are replicated by using the same It's as the 
HP OmniBook 5000's internal chips, which are disabled. By 
using the plug and play features of the BIGS, the docked HP 
OmniBook 500(1 ran have either the same configuration as 
the portable HP OmniBook 5000 or a different configuration. 

Control of the docking sequence is handled by the keyboard 
control lei using some control signals and die I^C bus. The 
I-C bus is used to read and write additional signals and to 
save and restore configuration information for the docking 
station. Fig. 5 shows the timing of the docking sequence. 

The user initiates the docking event by p lacing the HP Omni- 
Book 5000 on the docking station's receiving tray and pro- 
viding a gentle shove. Mien the docking station s detection 
switch is activated, the motor engages and captures the HP 
OmniBook 5000 and draws it onto the connector. When the 
docking connector guide pins begin to mate into the HP 



Flyback Charger Circuit 

The flyback transformer design of the HP OmniBook 5000 charger 
circuit can provide a wide range of output voltages because pf the 
energy storage, coupling, and isolation of the transformer [see 
Fig. 1}. During the first portion of a clock cycle, energy is stored in 
the primary side of the transformer. During the second portion of 
the clock cycle, the energy is transferred to the secondary wind- 
ing via the core's coupling. Because the current in the primary is 
cut off abruptly, the secondary voltage can become higher than 
the input (dl/dt is high and V = Ldl/dt). 

The secondary output current charges a large output capacitance. 
Using a high-frequency clock, the output capacitor's voltage can 
be charged up to any desired level and then the converter's cen- 
tral circuitry can be shut down until the output voltage has 
decayed by some desired amount for regulation. 

The isolation of the secondary winding allows for both voltage 
and current sensing to control the flyback operation This permits 
both current and voltage limiting, which are required with Li-Ion 
batteries. For current sensing, the voltage across the sense resis- 
tor is filtered and compared lo a set reference. When the output 
voltage has risen high enough to cause the desired current in the 
battery, the control circuit is turned off. Again, when the current is 
reduced by a desired amount to maintain regulation, the control 
circuit is reactivated. 
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Fig, 1, Flyback charger circuit. 



OmniBook 5000 the keyboard controller is notified by a non- 
maskable interrupt and it notifies the chipset that a Ik it-dock 
event is about to take place. The chipset then halts ihe Pen- 
tium processor and tristates the buses. When the two con- 
EU riurs ni;uc, the keyboard controller is notified by a signal 
on the connector. The keyboard controller verifies that the 
ducking station has a valid power good signal, and if it does, 
the keyboard controller signals the chipset to release the 
Pentium and begin driving the PCI and ISA buses. The BIOS 
first disables the interna] I/O chips and configures the I/O 
chips on the docking station before allowing ihe user to re- 
sume work. Depending on the operating system on the HP 
OmniBook 5000, a reboot of the operating system may be 



Fig. 4. HP OmniBook 5000 computer in docking slat ion 
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Fig, a. Docking sequence Anting 
ram. 



necessary to load device drivers for SCSI peripherals or 
i >Ther cards that may be plugged into the slots. 

The undock Sequence begins when the user either presses 
the undock key on the docking station or initializes an un- 
dock sequence via i he operating system (Windows® 95). 
When the keyboard controller receives the undock event if 
signals the chipset to halt the Pentium once again and re- 
leases control of the buses. It then signals the docking sia- 
lion via i lie l-i ' bus to begin I he undock sequence For the 
nininr, Tim motor starts and begins to ojn-i Hie IIP Omni 
Book 5000 from the docking station. The keyboard control- 
ler detects that undocking has occurred by monitoring the 
docking detect signal. It then tells the chipset to release the 
Pentium and drive the buses again. The BIOS then reconfi- 
gures the I/O devices back to the mobile configuration, 
Again, depending on the operating system and selection of 
peripherals, it may be necessary to perform m reboot 

CPU Thermal Management 

The Pentium cpu has a maximum thermal envelope of about 
7.6W. This power is rlissipated as heat in the CPU, The III' 
I MnniBook 5000 combines many techniques to remove the 
heat from the CPU to ensure both functionality and reliabil- 
ity of the product. Thr tape carder package (TCP) version of 
ihr Pentium is used to allow the case temperature of the CPU 
to be 3 lirfier than is allowed in the standan I ceramic j m kage. 
The TCP package is essentially a metal plate attached to the 
backside of the CPU die. Thr pads fin the ein nil side of the 
CPU conned to thin film conductors on ;i piece of cellulose 
(which looks similar to 35-mni film ) rather than using tntdi 
tiunaJ bonding wires. The fop side oi the die mid film are 
then covered with an epoxy coating to pi fitter rim bond ion 
nections and loseal du< f IU- from rontaminants. The net ef- 

fd ■• i ui this package is that ihe thermal heat resistance from 



the ( PC lo the outside mounting pad of the package is mini- 
mal. This feature allows us to operate the case temperature 
at 95°C versus 75°C for the PGA package. 

The TCP package has very little I hernial mass, so we need to 
move the heat euers^ away from Ihe package and out into 
the product Aluminum cast heat sinks are attached to two 
Sides of the CI'I package, both to the package epoxy and to 
the backside of the pa< kage through the use of many via 
boles under t 1 1 1 ■ die. This approach moves the heat energy 

from the CPU to a larger mass for further disposal mil 
of the product 

To gel the heal oni of the product the cast heat sink is at- 
rarlud to an extruded aluminum heat sink, which attaches 
to lln> back aluminum \/< ) panel This heat sink lias the 
ridges found in typical heat sinks so that the heat can con- 
vect out of vents in the top case. 

Toremow additional heal from the cast i 'PI. heal sink, a 
heat pipe technology is used | see Fig. 5), A heat pipe is basi- 
cally a small Camot engine that transfers heat from one end 
of the pipe to the other via a temperature differential, using 
a wicking action to recycle the fluid. The fluid in the pipe is 
just water that has been depressurized to allow it to boil at a 
lower temperature. When the CPU heat sink is healed lo the 
boiling \p >in1 ofthe wastei m thr brat pipi*. the water changes 
State from liquid to gas. This phase change extracts a large 
amount of thermal energy from the heal sink As the water 
boils, the wick inside the heal pi] >e brings cooler water to 
the CPU end and the gas moves down Ihe heal pipe lo the 
condensing end. When the gas in the heat pipe coots below 
the boiling point, thr energy taken from the CPU is released 
into the condenser. Tire condenser consists of a thin alumi- 
num stainped sheet. This sheet to attached lo the back of the 
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Fig. 6« Heal pipe principle. 

metal plate of the keyboard and the heat is spread out over 
the keyboard surface area. 

To prevent the (Tl I front generating excess heat during typi- 
cal operation, the ciiipsei provides different methods of con- 
trolling the CPU activity wiih the use of advanced power 
management, (APM). Software APJV1 is the most effective. It 
consists of having a running program shut the CPU clock 
down when there are periods of inactivity in the program. Of 
course, this method requires the software to be APM com- 
pliant, If the user is operating soft ware Thai is not APM com- 
pliant the ITP OmniBook 5000 can be set to use hardware 
APM as a default. Hardware APM is implemented by moni- 
toring the interrupts and major I/O function accesses. When 
the program is performing any I/O activity or the I/O devices 
generate an interrupt, a timer is resit lhal keeps the CPU 
active from one half second to eight seconds, depending uil 
the setting. If another event occurs before ihe timer times 
out, the timer will be set back to the full count. If the pro- 
grant is just executing out of the CPU memory and d^ie timer 
expires, then Ihe CPU clock is throttled back to 1/4 speed. 
This reduction lowers the power used by the CPU by about 
75%. Access to an I/O event will again sel Ihe timer to the 
full count and enable the CPU to run at full speed again. 

To prevent the CPU from reaching the critical case tempera- 
ture, active thermal feedback is employed, This technique 
measures the temperature of the CPU module and (he ambi- 
ent air inside the unit. The temperature limits for each are 
mot ti to red by the keyboard controller. If either limit is ex- 
ceeded, the CPU speed is reduced by clock throttling. When 
the CPU and ambient temperatures cool below dieir restart 
thresholds, the keyboard controller will again allow the CPU 
to work at full speed. For the thermistor on the CPU mod- 
ule, the feedback is fairly rapid because of the mechanical 
heat removal methods, and the CPU tends to run at an aver- 
age clock speed at which thermal equilibrium ts reached for 
the given operating conditions. In the case of the ambient air 
sensor (used to protect other ICs in lite notebook from over- 
heating) the effect of slowing do wit the CPU is not very rapid 
because of the large thermal resistance between the sensor 



and the CPU module. If this sensor trips the thermal feed- 
back, ihe unil will run ai a slower speed i 1/2 clock rate) until 
the air temperature returns to a cooler level. This rale was 
chosen so that the user can still operate the machine even if 
it takes several minutes for the ambient air to cool. 

Summary 

The technologies developed for the HIM mini Book 5000 
computer are designed to achieve the notebook features 
required for the future. The PCI bus will allow higher speed 
and functionality in video and eunmmnicaiions titan is pos- 
sible today. The hear transfer and modular assembly tech- 
nologies will permit incorporation of new r faster processors 
as they become available. The Li-Ion batteries will continue 
to provide more energy for a given weight, thereby making 
possible lighter products or longer - battery life. The instant-on 
feature allows the user the freedom to work whenever it is 
convenient, thus helping the customer adapt to a more mo- 
bile lifestyle. The PCI and ISA hot-docking technology allows 
the user to have full desktop functionality and performance 
when purchasing a notebook computer. 
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A Graphing Calculator for 
Mathematics and Science Classes 

The HP 38G calculator allows teachers to direct students and keep them 
focused while they explore mathematical and scientific concepts. It 
features aplets, which are small applications that focus on a particular 
area of the curriculum and can be easily distributed from the teachers 
calculator to the students'. 

by Ted W. Beers, Diana K. Byrne, James A* Donnelly, Robert W. Jones, and Feng Yuan 



The HP 38 1 calculate >r is a graphing calculator for students 
and teachers in mathematics and science classes. It features 
aplers, which are small applications I hat focus on a particu- 
lar area of the curriculum and can he easily distributed from 
calculator to calculator. This allows the teacher to send an 
electronic story problem to each student in ihe class. 

The HP 38G is I mill on the same software platform as the 
HP 48G family Of graphing calculators, 1 hut has a simpler 
user interface and feature set Equations are entered using 
algebraic format rather than the reverse Polish notation 
(KPN) found in most HP calculators. The features of the 
HF3SG include; 

• Graphical user interface 

• Function, polar, parametric, stairstep, cobweb, histogram, 
scatter, and box and whisker plots 

• Side-by-side split screen 
. Tallies 

• Unlimited, scrollable history stack 

• Symbolic equations 

• HP Solve numeric rool finder 

• Equal ion Writer display 

• Statistics tunc! ions 

• Matrix operations 

• User programming, 

Thr Imnlw are platform Of the HP 38G is very similar to ihai 
of the HP 48G the} botil have32K bytes of RAM, 512K bytes 
of ROM. the same CPU and the same cKsplay i in by M \*\\ 
els). They both have a two-way infrared link for sending 
information to a printer and for transferring information 
between two calculators, and an RS-232 link for calculator- 
lo computer communications. An accessory that allows the 
calculator screen to be displayed w uh an overhead projector 
works with both the III* !K(, and the IIP :W<;. bill the IIP 
38G cable connectoj has been modified so thai ihe overhead 
display accessory works with every HP 38G; no special 
handsel is required. 

The IIP is ease was redesigned in include a sliding plastic 

rover to make the HP :}8G more durable for use by yoimge] 
students UsO, Two keys were removed to give visual em 

pliasis to the navigation keys and to make the keyboard look 
less complicated 



Designed for and with Teachers 
We set I mi to design a graphing calculator for preealeulus 
-i « J' I e uis and teat hers. To help us do this, we formed an 
Education Advisory Committee consisting of eight high 
school, community college, and university teachers. We met 
with the teachers even- few months, and between meetings 
we kept in touch by email. 

The teachers Kilri us that they want to allow students to ex- 
plore mathematical and scientific concepts, and at the same 
time they need to direct the students and keep them Focused, 
In our first meeting with ihe leathers, we compared I his lo 
the idea of a child's sandbox: the child is given toys for play- 
ing and exploration, but within a protected, specialized envi- 
ronment. Thus, one of our main goals with ihe calculator 
software design was to encourage exploration by limiting 
choices. This led us to the concept of tiftlcf.s: an aplei is a 
small application that focuses on a particular problem 

HP 38G Aplcts and Views 

We based the design of aplets on die National Council of 
Teachers of Mathematics "three views*: graphic, symbolic, 
and numeric. Kacb problem can be explored using these 
different representations. For example, a mathematical 

function can be expressed as a graph (Fig. la i. m symbolic 
form ( Kig. lb), or using a table of numbers (Fig. lo. 

Apleis can be created by teachers (either directly on tlu< III* 
:M 1 or with I be assistance of a computer) and then "beamed" 
t • • ihe students 1 calculators using infrared transfer. This way, 
a whole classroom full of students can bay* their calculators 

programmed identically at the beginning of a lesson. Then. 
the students ran explore within ihe aplei on their own 
calculators. 

Each aplet packages the formulas, settings, and other infor- 
mation associated with a particular problem, if the user 
wants to switch from 0116 apiet to another, dus can be done 
without disturbing any individual aplet *s settings, since they 
are compartmentalized 

Several aplet* are hmii imo rtii HP38G, When the calculator 
is llrsr turned Ofl, these built-in apleis are empty. The user 
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Fig* 1. With the HP 38G calculator, a mathematical fuiicf ion 
can be expressed (a) as a graph, (b) in symbolic form, 'pt {c} 
using a table of numbers. 

must add some information, such as equations, notes, or 
sketches to make these aplets come alive. 

Using Aplets on the HP 38G 

Six different types of aplets are built into the IIP 38G; func- 
tion, parametric, polar, sequence, statistics, and solve. Typi- 
cally, a teacher will start with one of these aplet types, then 
custo naize it 1 >y add i ng pad i e u lar f u n eti o n s that de h ti e a 
certain problem, together with settings, pictures, and text 
directions. 

To start using a particular aplet that is already in the calcu- 
lator, the student chooses it from the HP38G library by 
pressing the LIB key. Continuing to explore the problem, the 
student may want to view the problem in different ways, and 
can do this by pressing the different view keys. PLOT, SYMB, 
and NUM display ihe graphic view, symbolic view, and 
numeric view, respectively. Additional views, such as split- 
screen views (Fig. 2), can be found by pressing the VIEWS key. 



The student or teacher can customize die graphical, numeric, 
and symbolic views for a specific problem by using the setup 
screens* It is also possible to annotate die problem by typing 
some text into the note view or by adding a sketch to Uie 
sketch view. 

The teacher and student can easily generate custom aplets 
that presenl new examples based on the built-in aplet types. 
An aplet is created by working with an aplet type and adding 
all of the customizing information that relates to a particular 
problem (see article, page SO), 

Main Components 

The keyboard (Fig. 3) reflects the seven main components 
of the HP38Gs functionality (from top to bottom on the 
keyboard): 

• Soft-keys for accessing custom behavior defined by soft key 
labels along the bottom of the display 

• View keys for moving among the possible representations of 
aplet data 

• Library key for selecting the current topic of exploration 
with aplets 

• Arrow keys for screen and menu navigation 

• Home calculator keys for numeric entry and basic calculator 
operations 

• Alpha keys for access to alphabetic characters 

• Editing environments for creating, editing, and managing 
objects such as programs, matrices, lists, and notes. 

Four of the key groupings are related as follows: first, a 
topic is chosen with the library key. Then, a way of looking 
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Fig. 2. The plot-table view is a typical split-screen vifu 



Fig. 3. HP «} calculator. 
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at the problem is chosen with the view selection keys. 
Finally, rhe peculiarities of the problem view are manipu- 
lated with the soft keys and the arrow keys. 

Softkey* 

keys are the top row of unlabeled keys, which are 
associated with the (dynamic menu labels displayed alon^ 
bottom of U»- They give access to context-specific 

custom behavior, t nlike the IIP 4SG. there is no "next-row*" 
key since all HP 38G soft key sets are limited to six items for 
the sake of simplicity. 

Mew Keys 

The view keys provide one-key access to the three National 

Council of Teachers of Mathematics representations of aplei 
data: graphical, numerical | tabular), and symbolic, plus 
annotation and sketch views for A ki interning a topic. Keys 
for setting up view parameters and managing split-screen 
views are also included. 
■ The plot view gives a conventional mathematical graphical 
representation. In most cases it looks like some flavor of 
plot output in thelUMst,. 

• The numeric view is generally a table of sampled values. It 
is a derived form of the mathematical object t except for 
statistics, where it is the defining view). 

• The symbolic view is generally an expression represent ing 
the mathematical object of interest. The variables are defined 
by the apleL This \iew is the defining form of the mathe- 
matical object (except for statistics, where it is derived). 

• The note view is a mini word processor that allows the user 
to create, edit, and view a text document associated with 
the apiet 

• The sketch view is a set of standard -si zed GRORs (graphic 
objects in HP 48G terminology) that explain the "story" of the 
aplet. The user can create, edit, view, and an i male pictures. 
Editing capabilities include lines, bnxes, circles, Text labels, 
and ftbii-a-Nkt'irh sivle drawing. 

Moving from view to view is the same as task switching, 
wtuch i \u 'uns i he user ruu always go ou to I he next task, but 
there is pi ol going back to somewhere] since tasks 

are no* being nested. 

The LIB key invokes the library which is the aplet select it m 
and management environment, in which different aplets 
(including those ihai are not built-in) ran be started, 
exchanged wiih ui tiers, and created by saving the state. 

The VAR key provides access tD variables and I be MATH ki> 

provides access to scientific functions ;md i <i k«»r < >perations 
and commands. These variables and operations are available 
whenever the user is using an edit line. 

Invoking the VAR Off MATH menu starts a subtask, which must 
be completed 01 cancelled, at which jioint the calculator is 
back where it was when the subtask was started 

The Library Environment 

This environment gives high-level access lo aplels. The user 
can selerl an aplet and manage the eurreul collection of 
aplet From within the library, the user can take a snapshot 
of a built-in aplet, giving il a name and a directory of its own. 
This is how aplets are generated for dissemination and how 



users show their work. Also, the user can import or export 
apiets from the library to another HP 38G or to a computer. 

Arrow Keys 

The arrow keys are used for all direction-oriented operations 
^uch as tracing a function plot, moving among fields in an 
input form, and selecting commands from a pop-up menu. 

The shift key can b a modifier for the arrow keys 

that signals motion ^all the way™ in the direction indicated. 

Home Calculator Keys 

The home calculator environment gives a familiar tool with 
a nice graphical interface. The user invokes it by pressing 
the HOME key. Inputs are displayed on the left side of a line, 
with the results displayed on the right side of the next line. 

The calculator keys are used to type numbers and to access 
basic scientific calculator functions. The ENTER key is used 
to terminate data entry, to select operations from menus, 
and in general, to make things happen. Some mathematical 
operations are available on the keyboard and other opera- 
tions and commands are available through the MATH pop-up 
menu. 

The ANSWER shifted key gives access to the variable called 
Ans, which always contains the last result. 

Alpha Keys 

The alpha shift key, A..2 t provides access to the alphabetic 
Characters, which are labeled on the keyboard overlay. 
Pressing the CHARS shifted key invokes the character 
browser, which provides access to characters that are not 
on the keyboard. 

I nlike the HP 486j there is no alpha lock key to confuse the 
user, The user can either press and release the alpha shift 
key before pressing each alpha charaeier key or hold the 
alpha shift key down while pressing as many alpha character 
keys as desired. However, an alpha lock toggle soft key is 
provider! in some editing environments. 

Editing Environments 

The HP38G has specialized environmenis for managing pro- 
grams, matrices, lisls, and Holes. When the user invokes one 
of the editing environments, a scrolling choose list of all I he 
existing objects of that type appeals, together with a soft key 
menu. From this environment, objects can be transferred 
bet ween I lie HP MG and a computer or another HP 38G* 
■ The program environment provides tools for creating, 
editing, storing, sending, receiving, mid running programs* 
Variables can be accessed through the VAR pop-up menu, 
Mathematical operations can be accessed from the key- 
board or through the MATH pop-up menu, and programming 
commands can be accessed through (he commands section 
of the MATH pop-up menu. 

• The matrix environment provides a two-dimensional matrix 
editor for creating, editing, viewing, sending, mid receiving 
matrices. 

• The list environment provides a list editor for creating, 
editing, viewing, sending, and receiving lists. 

• The notepad environment provides an environmenl for 
creating, editing, viewing, saving, sending, and receiving 
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Fig. 4« A typical input Form. 



Fig. 6. The function aptel '; j & >i sa r ifl i view input form. 



n\r documents. The tools tor editing notes in the notepad 
environment are identical to the editor for (he note view. 
The documents created in the notepad environment are not 
bundled with an aplet as they are in the note view. The note- 
pad environment can be used for (asks such as (Tearing, 
storing, and viewing lists or notes. 

User Int€*rface 

One of our goals for the IIP 3SG project was to leverage 
software from the HP 48G/GX calculator platform. For the 
MI J 4SG/GX we developed two primary general-purpose user 
interface tools; input forms and choose boxes, 1 

Input forms and choose boxes are interactive environments 
that are used to gather user input for a task. Input forms (see 
Fig. 4) are flexible, screen-sized dialog boxes similar lo 
those in other graphical user interfaces. The appearance and 
use ofinput fonn fields resemble, spreadsheet programs. 
Choose boxes (see Fig. 5) are either pop-up or screen-sized 
boxes optimized for selecting or working with one or more 
items from an arbitrarily long list. Input forms and choose 
boxes, along with some other user interface constructs, eon- 
Irihule to I he improved ease of use that distinguishes the IIP 
48G/GX from its predecessor, (he HP48S/SX. 

In the HP 38G, w T e found that input forms and choose boxes 
were a good match for the needs of the utility environments 
and niosl of the nine views available for working with aplet.s. 

Graphical User Interface Applications 

Input forms are used in most aplet views for entering a mix 
of settings and values. They're also used for gathering input 
to complete a task. For example; 

• The function aplet's plot setup view is an input form in 
which modes and parameters are specified (see Fig. 6'). 

• The solve aplet's numeric view r is an input form whose ap- 
pearance varies according to the equation to be solved (see 
Fig. 7). The flexible layout and labeling of input form fields 



are employed to generate a custom input form each time the 

view is entered. 

When an aplet is to be saved, a simple input form is displayed 

lo get the new aplet's name (see Fig. 8), 

The statistics symbolic view is a highly customized input 

form that scrolls to show more information than Ills on one 

screen (see Fig. 9). Choose box elements, like the up and 

down arrows indicating more information is available oil 

screen, help suggest the operation of this hybrid view. 

Choose boxes are used in a variety of views and utility envi- 
ronments wherever a lisl or related items needs to be man- 
aged. Here are a few examples of choose boxes in the IIP 
38G: 

The aplet library (see Fig. 10) is actually an elaborate choose 
box. 

Almost all symbolic views, such as the function aplet's 
symbolic view (see Fig. 1 1 J T are choose boxes. 
Choose boxes pop up within input tonus like the MODES 
input fonn (see Fig. 12). 

The VAR and MATH menus (see Fig. 13) are two-column 
choose boxes that Show categories of items plus the items 
in the selected category. 

As these examples illustrate, the look and feel of HP48G/GX 
input forms and choose boxes remain largely unchanged in 
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the HP 3S< i. However substantial reenguieeririg of die under- 
pinnings of these tools was required to match otto: as| 
of the EIP3SG*sose model, as discussed In the next section. 

Topic Outer Loop 

Many of the custom interfaces developed for the III* ESS 
used an RPL-languaue tool we developed called the parame- 
terized outer loop ~ Parameterized outer loop applications 
depend DTI the parameterized outer loop for routine key and 
erroi handling and display management .The graphical user 
interface c c 7 1 I > elements Introduced in the HP 48G/GX are 
also parameterized outer loop applications that automate 
routine matters of injinl entry, selection Of options, and 
presentation of output. 

In both the HP48S/8X and the HP 4SG/GX, the user interface 
was based on the notion of having a central environment 
(the user stack ) from which other applications are launched 
and to which applications return when completed All appli- 
cations on these platforms, including parameterized outer 
loop applications like the GUI tools, are based on this 
"function call 1 model: they start, run for a while, then end, 
returning the flow of control lo where the> started We call 
such applications modal. 

New Model, New Tool 

When w& win- investigating the use model for the llp:swi;. it 
became apparent that the function call approach to applica- 
tion management would not suffice. The HP38G is a tool for 
exploration, so we wanted to provide an environment that 
promotes wandering from chic subject area to another, or in 

IIP SHVi terms, from one view or aplei to another. 

To attain this goal we quickly determined that the modal 
nature of the parameterized outer loop and the applications 
based on it was too constraining, yci we weren't prepared to 
discard the wealth of useful tools and concepts w< had built 
up from the parameterized outer loon foundation. Further- 
more, we knew I } (ere were still plenty of times When the 
modal call and-return interface would still apply, such as 
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when pausing to gei further input from the user before pro- 
ceeding with a task. To accommodate all these needs, \\v 
developed the new topic outer I 

Topic Outer Loop Overview 

Where parameterized oute* loop applications are designed 

to preserve the environment from which they Ye launched 
and later restore that e nviron ment, topic outer loop topes 
are optimized for rapidly setting up and switching from one 

topic to the next Except with regard to the home environ- 
ment from which die topic OWtei b «»p is originally launched 
and to which it ultimately returns — after running many top- 
ics, perhaps — die topic outer loop doesn't preserve or restore 
a previous user interface since there is none to go back to. 

Hie most obvious examples of topic outer loop topics in the 
HP 3BG are aplets, but many other environments with simi- 
lar behavior are also topic outer loop topics — for example, 
the aplet library and the user program catalog {see Fig. 14). 

Like the param> u ] i/id outer loop on which it's based, the 
topic outer loop is launched from lite calculator's system 
outer loop and temporarily redefines the current use? inter- 
face until some exit condition is met. By design, the topic 
outer loop Operates \my similarly to the parameterized 
outer loop, but differs from the parameterized outer loop in 
two fundamental ways: 
• To better support i he standard two-tiered structure of HP 
39G topics, the topic outer loop manages two nested user 
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interface levels. The parameterized outer loop manages jusi 

one. 

The topic outer loop fully supports organized and efficient 

switching from one topic to another. The parameterized 

outer loop is designed to shul down completely before 

launching another application. 

The operation of the topic outer loop for starting a topic can 
be summarized as follows: 

If a topic outer loop is already running { 

Evaluate the old view exit handler 

Evaluate the old topic exic handler 

Set the topic entry and exit handlers 

Evaluate the topic entry handler 

Set the view entry and exit handlers 

Evaluate the view entry handler 

Set the remainder of the view user interface 



Else { 

Save the home user interface 

If error in { 

Set the topic entry and exit handlers 

Evaluate the topic entry handler 

Set the view entry and exit handlers 

Evaluate the view entry handler 

Set the remainder of the view user interface 

If error in { 

while not done with the topic outer loop ( 
Evaluate the view display object 
Read a key and get its custom definition 
If error in 

Evaluate the key definition 
Then 

Evaluate the error handler object 
} 

Evaluate the view exit handler 
Evaluate the topic exit handler 

) 
Then { 

Evaluate the view exit handler 
Evaluate the topic exit handler 
Error 
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The code selling up Hie lopic specifies the user interface and 
other environment elements unique to the topic, such as die 
topic entry handler and the view display object, when it runs 
the topic outer loop. This is how the behavior of the topic 
outer loop is customized. The topic outer loop is responsible 
for the key-display loop, low-level error handling, and juggling 
the topic and view entry and exit handlers and the saved 
home user interface. 

When an event occurs that calls for running the topic outer 
limp, the lopic outer loop may or may not already he run- 
ning As the first section of the topic outer loop overview 
illustrates, if a topic outer loop is already miming, switching 
to a new lopic is quick yet still gives the exiting topic an 
opportunity to shut down in an orderly fashion. Since it's 
common with the HP :18G to move from topic to topic with- 
out first returning home, this efficiency translates to faster 
performano 

Switching among views within the same topic is also com- 
mon, and involves a similarly efficient set of operations: 

Evaluate the old view exit handler 

Set the view entry and exit handlers 

Evaluate the view entry handler 

Set the remainder of the view user interface 

Reengineering the GUI Tools 

Although very similar in specifications and use to the stan- 
dard modal input fomi and choose box environments, ver- 
sions of these environments based on the topic outer loop T 
which we call Modeless environments, differ in the Following 
ways: 

• OK and cancel keys are nonfunctional, 

• The default soft key set does not include OK and cancel 
keys. 

• Task-switching keys are processed normally to allow r task 
switching. 

■ The results returned by the input form or choose box engine 
always consist of the confirmed exit values. No flag indicat- 
ing canceled or normal exit is returned 

To support modeless views and utility environments based 
on HP 48G/GX GUI tools, we adapted the input form and 
choose box engines to use the topic outer loop. However, 
modal input forms and choose boxes are also employed by 
the HP 38G. Rather than simply switch the engines from 
using the parameterized outer loop to using the topic outer 
loop, w T e modularized rhe components of the engines to 
enable the use of either. We then repackaged the modal 
versions of the engines to ensure backwards compatibility 
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for existing code using them. To make modeless input form 
and choose box programming as straightforward ns possible 
for programmers familiar with the modal versions, and yet 
still meet the requirements of ihe u ipfc i nifter U h rp we devel- 
oped tools to translate traditional modal input form and 
eho< i ; ^unienis and results to and from the specifica- 

tions required for topic outer loop applications. This greatly 
| »lified the reengineering of existing user interface code 
to make use of new modeless input forms and choose boa 
The process was if requiring only that the 

developer follow a few wvlHlot umented SJ 

Aplets and Views 

One of the key ideas of aplets is that they provide different 
ways of looking at a problem. For example, when exploring 
a story problem about speed and distance, the student ran 
look at a symbolic expression, a table of numbers, a graph 
of the distance fimction, or even a diagram showing a tortoise 
and a hare. These different ways of looking at an aplet are 
called views. The topic outer loop manages the transitions 
between Die views of an apleh The views an- implemented 
using the graphical user interface tools plus aplet data. The 
data associated with an aplet is encapsulated in a directory 
Structure inherited Irum the HP48G/GX, 1 

Apiet Structure 

Associated with each aplet is a standard set or informal ion. 
The topic outer loop uses this aplet information for apiel 
directory checking, topic switching, resetting, and so on. It's 
also used by the VAR menu and the VIEWS choose hox. Thr 
standard informal inn is 

• Topic II) 

• Initial view 

• Topic name 

• Special views data 

• Aplel-specifie va rlables 

• Topic entry procedure pointer 

• Topic exit procedure pointer 

• Topic* reset procedure pointer 

• Aplet directory checker procedure pointer. 

An IIP 38G aplet is a collection of aplet data and aplet views. 
Aplet data includea the aplei name, which is used in the 
library real variables like Xuiin and \max. whirl i are set via 
the plot sett^pvtew, symbolic expressions, note texh and 

sketches. An aplet usually defines at leas! ei^il views: plot 
symbolic, numeric, note, sketch) pint setup, symbolic setup, 
and numeric setup. The generic apiet contains Items such as: 

• Aplet name 

• Aplet topic 

• Attached library 

• Plot view procedure pointer 

• Symbolic view procedure pointer 

• Numeric view procedure pointer 

• Plot setup view procedure pointer 

• Symbolic setup view procedure pointer 

• Numeric setup view procedure pointer 

• Note view procedure pointer 

• Sketch view procedure poinin 

• Xmin variable 

• Vniin variable 

• Other shared variables 



• Aplet-speciftc variables 

■ List of symbolic expressions 

• Array of independent values for numeric view 

• List of strings for custom views 

text 

• List of graphics objects ft 

For aplets built into the HP 3SG, pointers like the plot 
procedure pointer refer to code built aim I 

aplet types can include a RAM-based support library 
containing new view procedures. All aplets must contain a 
basic set of variables, but specific apiet types may implement 
additional optional variables. 

View Structure 

Each aplet view is managed by the topic outer loop, typi- 
cally w rth the help of graphical user interface (<il 
like input forms. To customize its behavior; a view 1 1 >r &S 
GUI helper) specifies Objects that are used while the view is 
visible. These include the view entry and exit handlers, the 
display handler, and the key handler, among others: 

• Initialization procedure pointer 

• Exit proced 1 1 re pointer 

• Display procedure pointer 

• Key handler procedure pointer 

• Non-view --specific- key-allowed flag 

• Soft key menu description 

• Error handler. 

Symbolic View 

Normally, the symbolic view Ls the defining view for an 
aplet. When the user starts an aplet, its symbolic view will 
be shown so the user can enter symbolic expressions or 
equations to be used in the aplet 

The symbolic view is the generalization of the IIP 18G/GX EQ 
list. The EQ variable on the III* tSG is a list of unnamed sym- 
bolic expressions, winch are plotted rind traced together 
The IIP 3SG breaks this iui<» individual named symbolic ex- 
pressions thai have independent check marks, Expressions 
for a parametric function are further broken into real mid 
imaginary parts. The expression for a sequence is broken 
into iwu initial terms and a recursive relation. This simplifies 
editing and selection of symbolic expressions. Giving ex- 
pressions names in the symbolic view allows them to be 
reused in other expressions, home calculations, and pm 
gramming. 

Expressions entered in the symbolic view are checked for 
syntax errors and to a limited extent tor semantic errors. 
Expressions defining a sequence are fun her classified arrd 
transformed into an internal form for cache-based iterative 
evaluation, saving both rimi- and run-lime RAM space. An 
eval menu key is provided in the symbolic view for constant 
expression evaluation, expression sfrnpliffratfcm, and function 
unfolding. Fig. l'j shows bow the Fibonacci sequence can be 
defined and checked using ten keystrokes. (The EVAL menu 
key is shown when a command line is not active. It appears 
\v Jute OK appears in Fig, 1 5, ) 

The generic synnboiic vtevt Is based on the choose box enr 
tfine. which takes ©VET display handling to maintain eh* i i 
marks on the left of the screen and takes over key mapping 
for dynamic menu changes and editing of expressions 
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Fibonacci scqu ihqj ■ an •■• End checked 

i Ices, 

Because of the different requirements for different aplets, 
the generic symbolic view is implemented as a derived in- 
stance of the symbolic view with several data fields and 
virtual routines to be overridden. The information for a sym- 
bolic view includes: 

• Combine factor 

• Total expression 

• Group size 

• Single-pick flag 

• Soft key menu description 

• Edit menu description 

• Move focus procedure pointer 

• Special initialization procedure pointej 

• Edit tennhutior procedure pointer 

• Expression checker 

• Poststore procedure pointer. 

For example, the sequence aplet combine factor is 3 (three 
terms define one sequence). The total expression is 30 (up 
to 10 sequences allowed). The group size is 3 (every three 
terms will share one check mark). The edit terminator pro- 
cedure transforms definitions into internal form. The move 
focus procedure updates menu soft keys with (he current 
sequence name. The expression checker rejects lisl < u m;j 
trix expressions and initial terms that depend on the se- 
quence independent variable n. 

The symbolic view for the statistics aplet posed a mw 
problem because we decided to show two expressions on 
One line* one for data and one for frequency, which is not 
supported by the choose box engine. The statistics symbolic 
view is implemented by customizing I he input form to mimic 
a scrollable choose box with a check mark and two columns 
of data. 

Setup Views 

After expressions are set up, setup views are the natural 
places to go for setting the parameters for further explora- 
tions, The pint setup view is the main setup view, similar to 
the plot dialog box on the HP 4HCu but enhanced with wider 
fields and a double-page design. The plot setup view, I he 
symbolic setup view r . and the numeric setup view are all 
based on the input form engine. 

Plot View 

The plo! view is the most complicated of all aplet views. 
Students will spend most of their time here exploring the 
behavior of curves graphically and interactively. 
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Fig. 1$. Box and whisker plol 

The IIP 38G takes the DRAW command in the IIP I8( i/GX plot 
window and improves it by implementing a *smart redraw.*' 
When switching back from other views, the picture, cursor 
position, and display mode are restored to the same sidle 
instantly except when the defining parameters are changed. 
Plotting can he slopped and resumed later. When the user 
tries to move the cursor beyond the screen boundary, the 
graph shifts and redraws live scrolled -in portion, Zoom 
options are put into a choose box with more descriptive 
names, tnstead of taking the current point as Hie liisi point, 
the box zoom prompts the user to seleel the flrsl point 
Tracing is improved and extended to Statistics plots. Fig. lb 
shows hating on box and whisker plots. 

For the function aplet , more areas of exploration are sup- 
polled through the FCN menu key, which displays a choose 
box with choices of root, intersection, slope, area, and ex- 
tremum. Fig, 17 show r s the display for an area computation. 

The plot view has overridable routines for curve drawing t 
curve tracing, FCN key handling, DEFN key handing, and other 
functions. For example, the function, parametric, and polar 
aplets share ihe same plot loop with different preprocessing, 
but the sequence aplet uses another plot loop for handling 
the discrete independent variable n. 

For tracing, the sequence aplet implements four-way scrol- 
ling: the screen will scroll when die cursor is moved off- 
screen in all directions. The scatter plot overrides the FCN 
menu key to calculate and display a data-fitting curve. The 
information for a plot view T includes; 

• Draw procedure 

* Independent variable ID 

• Softkey menu description 

• Display procedure pointer 

* Key handler procedure pointer 

• Pointer display procedure 

* Draw r axes flag 

* Draw grid flag 




RfcEH: 2,02042712^ 
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Fig. 17. ^rea computation accessible via the FCN sofrk»-y 
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• Axis labels 

• Display coordinate procedure 

• TVaeing procedures 

G0« >rdinate display procedi a 

• Equation display procedure. 

Numeric View 

The numeric view lets a student explore the functions denned 
in t he symbolic view in numeric form. The leftmost column 
displays values of the independent variable ( except for s la- 
list ics) and adjacent columns represent function results. 
There are two basic forms of the numeric view; automatic 
( Fig, IS i and build-your-own (Fig, l§). The automatic view 
displays a series of independent values wilh a si ailing value 
and a step specified by either the numeric setup view or the 
variables NumStart and NumStep. 

The BIG menu key lets the student display the numbers using 
a larger font. The ZOOM key provides a series of options tor 
changing the start and step values for the independent vari- 
able display. 

When the cursor is moved to the upper or lower boundaries 
• >f i J ie i lisplay 1 he table scrolls to show adjacent values. The 
table can also be reset by en feting a new value for the inde- 
pendent variable in the leftmost column. 

The build-your-own numeric \ieu is useful for creating a 

table of interesting values. The values for the independeni 
variable column in the build -yonr-own numeric view m 

accessible via Hie Numtndep variable. 

The information for a numeric view includes: 

■ Initialization procedure pointer 

• Numeric /-jhm i Gho 

• Soft key menu description 

■ Display procedure pointer 
Key handler procedure pointer 

• Split plot-table configuraiion inlbi niation. 



Plot Table View 

The split plot-table view allows a student ro combine the 
plot and numeric views (Pig. 20). 

This view is implemented primarily as a plot view, with the 
right side of Hie display being a small numeric view that 
updates to reflect the position of the plot cursor As the 
student moves the cursor lmm one function to another, the 
right side of the table changes to reflect the function being 
traced The DEFN menu key displays the current function ar 
l he bottom of the display Tins lets the student display (he 
symbolic, plot, and numeric views of a function all at once. 

Note View 

Besides main aplet views like plot view, symbolic view, and 
so on, auxiliary views like the note view and sketch view r are 
provided to add textual and pictorial descriptions to an aplet. 
The note view j Pig, 21 ) can be used to edit and display a 
i ex i siring an ached to an aplet. The note can provide infor- 
mal ion about the aplet s subject, a suggested sequence of 
exploration, or the supported keys. The note view is basically 
d wurd-w rapping text editor with a b-line-by-22-t liara< n i 
display. 

Although the original HP 4K< i/i IX edit line supports multiple 
line editing, itidi vicinal Hues are handled independently. 
When more than 22 characters are inserted into aline, thai 
line gets scrolled lo Hie left without affecting the rest Of the 
lines. The HP38CJ note view is implemented Independently 
from i he edit fine code. Direct display routines are Coded to 
show a rharariei Of B string at a specified location without 
generating intermediate GROBs. System-level keyboard han- 
dling code is modified to implement a general blinking cur- 
sor display scheme. Besides the text string to he edited, the 
note editor maintains a linewidth array for wurd wrapping 
bookkeeping. 

[continued on page 55] 
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Fig, 19. Rmltl-yuwr-iiwn numeric view 
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Distributed Software Team 



The HP 38G calculator was the first product to be developed by Hewlett- 
Packard's Asia Pacific Personal Computer Division after the charter for 
handheld products was transferred there from Corvallis, Oregon. The 
software team was split between Oregon and Singapore, srj we learned 
to make good use of communication technology, including Internet tools. 

We had to figure out how to overcome a separation of over 9 r 000 miles 
and eight time zones. At the end of normal working hours in Oregon, the 

Singapore workday has just begun Our specific communication needs 
included same-time, different-place meetings and documents that could 
be accessed anywhere, anytime 

Same-Time, Different-Place Meetings 

Two of our Oregon learn members were already experienced telecom- 
muters, working at home a few days each week. They pioneered the idea 
of "virtual team meetings." Our first virtual meeting experiments were 
practiced with everyone in the office, sitting in our individual work areas 
with telephone headsets and a shared window running on all of our 
computers, so that we could all view and edit the same document at the 
same time. 

We were able to work out the initial kinks in the process by standing up 
and shouting to each other if necessary The next step was to link our 
two telecommuters from their Oregon homes. When we added our two 
Singapore engineers, we were already familiar with the procedures and 
etiquette for same-time, different-place meetings. 

The team used HP 9000 workstations as well as computers at home that 
were connected to the workstations in the office using a LAN connection 
over 56-kbit/s frame relay lines. The applications used for sharing docu- 
ments during meetings ran on our workstations and included Collage and 
HP SharedX. These applications allow a group of people to view and edit 
the same document simultaneously. However, our more typical way of 
sharing documents during meetings was by individually accessing our 
team's Worldwide Web pages. 

Anywhere, Anytime Documents 

Project documents are used to keep people informed of discussions end 
decisions and to provide product descriptions for the extended team 
members. Our challenge was to create and maintain project documents 
that would be accessible from many different locations. Our documenta- 
tion process made extensive use of Internet technologies; hypertext 
documents, graphical browsers, and electronic mail 

Hypertext documents contain links to other documents. They can be 
easily created with any text editor using a special kind of formatting 

called Hypertext Markup Language (abbreviated HTML). Our team 
members were all able to get started with simple hypertext document 
creation after only a few minutes of study. 

It became apparent to us that HTML was the best choree for developing 
and maintaining our project documentation, because 

• As a text-based source file format. HTML \s compatible with our source 
code control system This allowed us to maintain HTML documents with 
the same familiar tools that we used to maintain source code, 

* A variety of HTML browsers such as Mosaic and Netscape are commonly 
available for multiple hardware platforms, which ensured that each team 
member could access our documentation 



• The hypertext nature of HTML documents provided a natural and exten- 
sible means to link together our rapidly growing documentation set 

We started with an HP 3SG project home page. It had finks to conven- 
tional software project documentation, such as our external reference 
specification (ERSI documents, which were also authored in HTML But 
the power of linked documents to disseminate information also led us in 
new directions that supported the HP 3flG project development process. 

In past projects, we often regretted our inability to look back at topics 
discussed through less formal means like email, but with our HP 38G 
home page and tools to support HTML document generation, we finalfy 
had the enabling technologies to overcome this limitation. We began to 
archive our group email discussions and link them into our HP 38G proj- 
ect home page, indexed by date, author and subject. On frequent occa- 
sions (sometimes as a group during a teleconference) we would refer 
back to these email archives to revisit a line of reasoning about design 
choices. 

The success of the discussion archival technique led to the side benefit 
of a uniform, centrafly maintained marling list for software team members 
Over time we expanded this concept to include multiple discussion 
groups, each with associated email archives and each specialized for a 
different audience. 

Soon we were using the HP 3813 home page to collect information that 
was previously scattered throughout paper documents or engineers* 
minds. For the first time, documents detailing the setup of our software 

debugger systems, EPROM burners, and more were readily available 
around the clock. 

Other departments involved with the HP 38G began to seek out the re- 
sources we made available through the HP 3SG home page, and it was 
quite rewarding for us to be able to direct them to our pages The frustra- 
tion of trying to coordinate delivery of information by hand was becoming 
a distant memory. Some departments, with our encouragement and sup^ 
port, began making information available through linked documents 
These we gladly added to our project page h making it more valuable for 
all parties. For example, when our colleagues in Singapore had industrial 
design drawings to share, these were made available to all through the 
HP 38G home page, and the QA department's software [est plans were 
added so that engineers could review and comment on them to ensure 
complete test coverage. 

Conclusion 

Our use of linked HTML documents has increased steadily since the HP 
38G project. We now have more email discussion groups, our own Web 
server to simplify access lor remote connections, a team home page with 
links to all of our project home pages, a dynamic team calendar of 
events, a "what's new" service for quickly learning what's changed, and 
a searching service for finding specific topics amongst our wealth of 
interconnected documents We expect exciting new developments to 
further increase our productivity as we expand our knowledge and use of 
the Web. 
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Sketch View 

Some people believe that a picture is worth a thousand 
worcK so the HP 38G generalizes the HP 4- : tmap 

editing features to form an aplet sketch view. With the 
sketch view, ihe user can edit and display a set of bitmaps 
attached to an aplet. Holding down the page-down or 
page-up key shows a prestored animation sequence 
22 

Compared with the HP 4SG/GX. the MP :>sd limits the bit- 
map editing features and impi user interface and 
implementation. The HP 38G Implements a rubber band 
algoritJun when the user drags the second point to define a 
line, rectangle, or circle, The circle drawing code uses a fast 
integer-based iterative algorithm. The user can drag a text 
string in the small or medium font to any location. The HP 
38G can store a selected portion of a screen into a GROB 
variable and recall it. When bitmaps are stored back into an 
aplet directory, they ate first brimmed to the minimum 
enclosing rectangle to save RAM space. 

Additional Mews 

Each aplet type defines additional views available in the 
VIEWS menu. For example, the function aplet offers some 
hybrid views and some p reconfigured plot views. Fig, 23 
shows the function VIEWS menu. 

In addition, a user can define a new set of special views thai 
provide high-lev i 1 t> n fe for an aplet Such a custom interface 
makes the aplet easier to explore and hides details of the 
calculators operali* m. 
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The Home Environment 

The f reefonn home environment fills the traditional calcula- 
tor role of supporting quirk calculations. The user enters 

issions in algebraic form and the value of the expression 
(usually a number) is returned. 

Unlike apleis. the home environment provides access to all 
calculator resources, including lists, matrices, graphics 
objects, and programs. 

The History Stack 

The text of the inpui and die result are stored on a history 
stack (Fig. 24a), The user can review the items on the history 
stack and revise those it ■ ins SB pans of the current input 
(Fig, 24b), Expressions and equations on the history stack 
can he shown in two-dimensional mathematical format 
(Fig. 24c), 
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Fi«, 22. An animation sequence in sketch 
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Fig. 25. Fraction number format. 

The HP 38G includes special features to help beginners. To 
helj > students learn about fractions, the HP38G has fraction 
number formal, which uses continued fractions to convert 
m -iilrs lo rational form (Fig, 2 r ij. To help students unfamiliar 
with standard algebraic syntax, the IIP 38G attempts to 
interpret ill-formed expressions as implied multiplication 
(Rg.2«>). 

The Variable Ans 

Each time the user inputs an expression, the value of the 
expression is stored in available named Ans, This current 
value of Ans is placed on the history slack, and the name Ans 
can be used in the next calculation. Even when the user 
enters a command that performs some action bul doesn't 
return a value, the current value of Ans is placed on the 
history stack. 

If the user starts an input with an infix function such as +, -, 
*, or A the calculator inserts the name Ans first, This saves 
keystrokes for tasks such as balancing a checkbook (Fig. 27), 
If the user presses ENTER without input, tlic pre\ ious input is 
repeated (Fig. 28). Tins saves keystrokes for iterative opera- 
tions. 

The VAR and MATH Menus 

To organize its extensive resources, the HP 38G presents the 
most -used variables ami functions on the keyboard. Addi- 
tional resources are available hi the VAR and MATH menus. 
These two -column menus offer specific items in the right 
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Fig. 27. Checkbo laiiotisia die home e&yfrontnenl 

column, categories of items in the left column, and broader 
choices on menu keys. 

In the VAR menu ("Fig. 29) the user can choose to examine 
variables either from The current aplet or from the shared 
hi hup variables. The user also can choose either thp name or 
I he value of a variable, 

In the IIP 38G most variables are strongly typed, that is, for 
many variables the value must be a specific type. For exam 
pie, the variable X must contain a real number, Zl must con- 
tain a complex number, and M2 must contain a matrix. Sev- 
eral classes of variables contain exactly ten variables, such 
as the ten complex variables Zl, 22, .... T% 20 f Fig. 30), 

Variables are used not only for mathematical objects, but 
also tor modes. For example, storing the constant, Degrees 
(whose numerical value is 1) into the variable Angle selects 
degrees angle mode. 

The classes of home variables include complex numbers (Z1 
to ZO), graphics objects (61 to GO), aplet s (user-selected 
names), lists (Li to LO), matrices (Ml to MD), modes (fixed 
descriptive names), notepad (user-selected names), pro- 
grams (user-selected names), and real numbers (A to Z, 8). 

The MATH menu (Fig, 31 ) offers additional functions, com- 
mands, and constants not available on the keyboard. The 
categories of functions are: calculus functions, complex- 
number functions, constants, hyperbolic functions, list 
functions, loop functions, matrix functions, functions of 
polynomials, probability functions, real-number functions, 
statistics functions, functions for symbolic manipulation, 
tests, and trigonometric functions. 

Lists and Matrices 

For these composite variable types there are catalogs that 
report the variables' sizes, along with special editors to enter 
and modify the elements. The catalogs and editors are tasks. 
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Fig- 28, IF the user presses ENTER wuli- >u1 input, Ehi previous 
■ is repeated. This saves keystrokes foi Iterative ■ \ ■ rations. 
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Fig, 29. VAH m tome environment 

so the user can easily move among aplets, home, catalogs, 
and editors. The list editor (Fig. 32) is one-dimensionaL The 
matrix editor is two-dimensional (Tig. 33). 

Lists and matrices can also be used as functions of an index 
value. For example. LI is a list, while Ll(2} is an expression 
whose value is the second element of L ] 

Notes and Programs 

For these text variable types there are catalogs that show 
the user-selected names and editors that allow freeforni text 
input. The notepad holds simple text files such as phone 
lists (Fig. 34). 

There is a program with the fixed name Editline, which holds 
the most recetn mpm from the home environment. The user 
can choose to edit the most recent home input from within 
the program editor, or to execute the program Editline from 
the home environment by simply pressing ENTER. 

Programs aren'l parsed until I he firsl time ihey're run. 
Because of I his, and because the program editor is a task. 
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the user can write a program a little at a time, leaving the 
program in an invalid state between editing sessions. Fig. 35 
shows part of a program. 

Commands that perform some action and return no result 
can appear only within programs (which includes Editline). 
The categories of commands are: commands DO control 
aplets. branch commands, commands for scaled drawings, 
commands to manipulate graphics objects, loop commands, 
matrix commands, printing commands, prompt commands 
for input and output, and statistics commands. 
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Programs that Support ApJets 

The most important purpose of programs in the IIP 38G is to 
support the user-defined entries within ihe VIEWS menu 
(Fig. 36). Using the SETVIEWS command, the user specifies a 
number of special views that represent the tools for manipu- 
lating the aplel. These tools can be presented at a high level, 
using terms relevant to the particular aplet and hiding the 
actuaJ methods of the calculator frnm the aplel user 

The specification for each special \iew r includes a prompt, 
which appears in the VIEWS menu. It also includes a program, 
which is run when the special view is selected, and a view 
specification, which determines the standard view (plot, 
symbolic, etc. ) to be started w r hen the program is done. 

If an aplet has special views with start or reset prompts, 
pressing the menu keys START or RESET within die LIB catalog 
(Fig. ffl) automatically selects the corresponding special 
view. 

While the prompt category of commands enables program- 
matic interaction with the user, the main goal of HP 38G 
programs is to modify the configuration variables of the cur- 
rent aplet, After the program runs, the standard view speci- 
fied in the VIEWS menu slaris. operating with the configura- 
tion left by the program. This approach has the advantage 
that the interface to the siandard view is familiar to the user. 



Start 

bide Lengths 



Perimeter 



Area 

Polygon Props 



731 
73? 



?S6H 

7hM3 



inNCL OK 



$8«§«ftPLET 


LmMimmmm 


IPnluQirloc ■ 


rOlHglQps ■ 


Funct ion 
Parametric 
Polar- 
Sequence 




T 


I SAVE ]RESET| 3QRT 


I SEND 


RECV I5TARTI 



Fig. 3ft. VIEWS n lenii with usor-s \ .. •< ■ i; 1 1 vlu xvs 



Fig, 37. UB catalog, 

AJ1 the components needed for special views are automati- 
cally managed by the HP 38G, The menu of special views is 
stored as a pail of the aplet, and I he programs used by the 
special views are automatically transferred with the aplet. 

This makes aplets simple to use: a single request gets the 
aplet and associated programs, and the VIEWS menu offers 
the high-level tools that allow the user to focus more on the 
content of the aplet and less on the calculator. 
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Creating HP 38G Aplets 

This article explores a simple aplet and shows how to construct an aplet 
called PolySides. 

by James A, Donnelly 



In designing an aplet for the HP 38G calculator, it s impor- 
tant to remember two guiding principles of the HP 38G de- 
sign. First, the design recognizes that in a classroom setting 
there is i and should be i a large discrepancy between the 
amount of information entered into a graphing calculator 
and the amount of information produced by the calculator. 
We sough i to minimize tte calculator input required of the 
studeni and ihe u>;u her and maximize the returned informa- 
tion. Secondly, we sought to exclude irrelevant possibilities, 
By reducing irrelevant choices you focus the users attention 
on the subject of interest and avoid distractions from things 
thai don't matter Many choices made during the design 6t 
the HP 38G were based on this goal. 

Aplets contain information and have views. The information 
in an aplet consists of every major piece required to produce 
the views; the equations, setup information, mode informa- 
tion, sketch or text annotations, and attached libraries or 
programs. In titis article we'll explore a simple aplet, then 
look at an aplet called PolySides and examine how T it was 
constructed. 

Using Built-in Aplets 

When the KPSSG is first tinned on. the built-in aplets Me 
empty There's no equation, note, or sketch. When the user 
adds ibis information, these aplets come alive. Son can save 

anaplel at anytime, so r m start one project. Change 

in inidsfream to another, Hun come back lo fche first 

(Because the nppeannu <■ oJ ihc screens depends on tfee 
infiniu;i!inn you enter, I be screens on your calculator may 
look different from the example screens lit this article* I 

A simple way to illustrate the nplct <uneept is lo explore the 
equation SINIX 2 VX. Select the function aplet. press SYMB, and 
enter the equation. <*■ 



m&M FUNCTION SYMBOLIC MIEW^ 

• FKX)=SIHO^>/X 



F2<X>= 



F300 = 
F4<X>» 

F5<X>= 



EDIT • CHK V. 



V 



Now press PLOT to see the plot using the default plot 
parameters. <•> 



\ i ,>» .*. y" h /V »i r h 



TV 



#\ 



X » jT l / H j/;* * * 



*> 



FICH): .6733297 lEHJIH 



Use the box option under ZOOM to look at a smaller area of 
the plot. ^ 




You can see the plot scale by pressing [shift j PLOT lo see (lie 

plot setup view, ♦ 



M'lWffi'A'i' 



g;; * FUNCTION PLO T SETUP m®® 

kbng: EHflH 3.6 
vrng= -.95714,.. 1. 1 
stick: 1 vtick: 1 

RES: Fast er 

ENTER MINIMUM HOfilSONTHL VALUE 



PAGE T 



At this point, yon ha\e an aplet that s completely dedicated 
In your Interest In the Function SJN(X 2 )/X, and the aplet can be 
Saved under a unique name or transmitted to another UV 
38G or a computer. When the aplet is restarted on the origi- 
nal or another EIP38G, all modes and scales are set just the 
way I [ley were saved 
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Exploring the PolySides Aplet 

The PolySides aplet is designed to explore how ;i regular 
polygon can approximate a circle as the number of sides 
increases, Poly Sides can be loaded from a disk or another 
IIP 38G in a single operation from the LIB catalog. Once 
loaded, PolySides appeals in Hie aplet library. ♦ 



After the circle properties have beep viewed, the note view of 
the aplel is displayed. The PAGE menu key switches between 
the pages of the note. ■*■ 



8HPLET LIGRAfi'i'lig 



PolySides 



Funct ion 

Statistics 
Parametric 
Polar 



SAVE RESET SDRT SEND RECY START 



POLYSIDES NOTES 

Press [VIEWS] to 
explore how the side 
1 engt hs * per i met er * 

and area of a polygon 
change w i t h t he number 
of sides. 
B2H 



PAGE ¥ A...Z BKSP 



We are now just a single keystroke away from exploring the 
aplet. To begin the exploration, press START The motivation 
for the lesson is displayed first. + 



Explore how a regular 
polygon begins to 
approximate a circle 
as the number of side:: 
increases. 

Press any key.,, 



POLYSIDES NOTE 

Equations used are' 

H = No. of sides 
FlOO = Side length 
F2CK) = Perimeter 
F3O0 = F\rea 



A.„2 BKSP 



To see a sketch of the problem, press SKETCH. ■*> 



After the introduction has been read and a key pressed, the 
next step is to enter the radius of the circle to be approxi- 
mated, m 



388888888 set 

RADIUS: [ 
FIRST ENTER 


CIRC 


:le radius «888$8 










L 




THE 


CIRCLE 


RADIUS 




1 EDIT | | 


- 


1 


KANCLl 


_DK_ 



r^K 




EEQEH5I3 



^NUMBER OF SIDE: 
R=F;rtDIUS 

i-=F1=i-|0E LENGTH 
P=FE=PEMMETEf; 
F=F3=ftFiEft 



iiran nnnBi 



So far we have seen a pretty complete summary of the lesson 
with less than a dozen keystrokes. Now we can begin to 
explore how may sides are needed to approximate a circle. 

Our central point of departure for PolySides is VIEWS (as 
mentioned in the note view). ♦ 



After the radius has been entered, the properties of the 
circle are displayed. ^ 



Circle Proper 


-t; 


Les 


Rad i us = 
C i r cumf er ence= 
Rrea = 


1. 
6. 

C' i 


,00 

ZQ 
14 


Press any key,,, 








These choices let you determine what aspect of a polygon 
approximation to a circle you'd like to explore. To explore 
how the perimeter of the polygon approximates the circle. 
move the highlight down to Perimeter and press OK. The plot- 
table view is presented automatically. ^ 
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mm 



FCN DEFN 



This is one of tin- MP )8G"s split views, showing the plot and 
numeric views of the perimeter approximation at the sai 
time The variable X represent ttte number of sides, and the 
equation stored in F2 returns Mu- perimeter as a function of X. 
^ing i he left or right arrow key moves the cursors for the 
plot and numerie \iews simultaneously. When the cursor is at 
i he Mi w\gr of the plot, the table on the right shows die rapid 
change of the perinieter front a triangle to a nonagon. ^ 



F2 



E3 S.llfilS 


fi 


5.656B5 


5.BF7BS 


i§ 


£ 


1? 


e.iiirni? 


SB 


b.l2ER3 


SI 


b,15b3b 



FCN DEFN 



To see the equation, jus I press SYMB. ^ 



PDLYSIDES SYMBOLIC YIEMg 



F2(X>=X*C2*R*SIN<1. 



F3GO= 
F400= 
F5<X>= 



5*X*R Z *SIN<», 



EDIT VCHK X 






The symbolic view is where aplet equal i< his are stored The 
check mark beside F2 indicates lhat when a plot or numeric 
view is displayed, F2 will be used. Another view of the equa- 
tion is available hy pressing SHOW. ♦ 




Notice thai after the Introduction there is no h\v(\ order of 
events. You can change ro any of the views at any lime or 
press HOME a! any lime to do a short calculation. Part of the 
design philosophy n I aplet s is to let the SttidetfJ explore the 
lesson at will without following any particular algorithm, 
I mm i you Ve explored the approximations t<« the perimeter 
and area, and perhaps explored the HTert on side lengths. 



i nay deckle that a polygon with 57 sides yields a fair 
approximation to the circumference of a unit circle, ♦ 



X 



53 
5H 
55 



F2 



M 



fi.37RBH 

EB0005 

fi.aaona 



57 
EMS\ 



BIG DEFN 



Now you can look at a summar\ d a "-sided polygon by 
selecting Polygon Praps (for polygon properties i limn the VIEWS 
choices. ♦ 



Start 

Side Lengths 

Perimeter 

firea 




?H2b 
7R51 
^laH 



(AN(U DK 



Press OK to select this choice. Since the cursor was last on X 
= ")7, 1 he number of sides defaults to B7 ♦ 



^lii^iMUMfER 


OF SIDES £M 




SWBS 13S 


1 




ENTER NUMBER 


DF 


SIDES 


fED.T | | 


^^ 


KflNCLI 


BK 



All er the use* accepts (or alters) the- number of sides, the 
polygon data is displayed. •» 



57 Sided Polygon 

flpproxi mating circle 
of radius 1.08 
Side length* B. 11 

Press any key,,. 



57 


Sided Pol 


ygon 


PolyQc 

i£ ■_*■_» 
f_' ■ i^'_' 

Circle 
6.28 
Press 


«n peri met er= 
> circumf erence= 
any key... 
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57 


Sided Pol 


ygon 


Pol 

C I r 
3« 

Pre 


ygon area= 

"cle ar?3= 
14 
ss any key,,, 





Now we've observed that a. 57-sided polygon docs a fair job 
of approximating a unit circle. More explorations are pos- 
sible. For instance, if the circle has a very largo radius, how 
many more sides are required for a polygon to closely 
approximate the circles area? 

All i r the last polygon property screen has been acknowl- 
edged with a keystroke, the VIEWS menu is displayed, m 











ISt art 






Side Lengths 

Perimeter 

firea 

Polygon Props 






1 1 1 1 ICAWLI DK | 



This lets you start with anoi her circle or go back to find a 
different approximation. 

Notice that the keystrokes involved for the entire exploration 
have been oiienfcd to the views. Wp haven't entered a single 
hil oi'setup or .scaling friformation beyond the radius of the 
circle being approximated. This is the goal of a well-formed 
aplet; more attention Ls directed io the lesson and less atten- 
tion Ls directed to die mechanics of the calculator You can 
imagine a teacher distributing this aplel in a classroom for 
part of a day's lesson. 

If you're familial with the HP48(1/(JX calculators, you 11 
notice thai variables like ED and PPAR have ru'vrr |nrn men- 
tioned, even though we changed die equation and plot scaling 
parameters several times. Furthermore, we never wenl near 
an input form to set the scale manually (although we could 
have done so by pressing [shift] PLOT to display the plot setup 

VH-W J. 

Building the PoIySides Aplet 

PoIySides was constructed using Hie function aplet and five 

user programs attached with ihe SETVIEWS command. 

Beginning with a reset function aplet. the equations, note, 
and sketch were entered directly on the calculator. The 
equations are: 

- Side Length fi (x)=2*r*sin(180/x> 

• Perimeter F2 (x)^x*2*r*sin{180/xj 

• Aiea F3 !X} = .5*X*R 2 *SIN{3G0/X) 

Then five programs were entered, one for each entry in 
VIEWS. After the programs were entered, they were attached 
to the aplet with the SETVIEWS command. For convenience 
during aplet development, a separate program. SetPofy Views, 



was entered that contains the SETVIEWS command. SETVIEWS 
allows you to customize die VIEWS key with your own entries 
and selected entiles from I lie default VIEWS choices. SETVIEWS 
takes triplets of arguments, Each triplet contains the prompt 
that will appear in the VIEWS list, a program name, and a 
number corresponding to the view that should be displayed 
after the* program is executed. The SETVIEWS command for 
PoIySides looks like this: 

SETVIEWS 

"Start";" . Polyl" ; 8; 

"Side Lengths'' ; " , Poly2 " ; 16 ; 

"Perimeter"; " .Poly 3" ; 16 ; 

"Area"; " . Poly4"; 16 ; 

"Polygon Props" ; " . Poly 5 " ; 7 ; 

When Side Lengths is selected, the program .Poly2 is executed, 
then view number in is displayed. View number 7 is the VIEWS 
list, view number 8 is the notes view, and view number lb' is 
the split plot -table view. A SETVIEWS convention is thai if a 
prompt is named Start or Reset, it is associated with the START 
or RESET menu key in the LIB catalog The PoIySides aplet 
takes advantage of I ids feature so ihal pressing START in die 
LIB catalog gets a student underway in a single keystroke. 

The programs are listed below. (Note that the translation 
CGdes used are I he same as translate code 3 on the HP 
48<VGX.) 



Pnlyi (Start) 

ERASE i 

DISP 1; "Explore how a regular"; 

DISP 2; "polygon begins to": 

DISP 3 ; "approximate a circle": 

DISP 4; "as the number of sides": 

DISP 5 i "increases . " : 

DISP 7; "Press any key...": 

FREEZE : 

IF R\<=0 THEN 1\|>R END: 

INPUT R;"SET CIRCLE RADIUS"; 

" RADIUS:",- 

"FIRST ENTER THE CIRCLE RADIUS" 

ERASE: 

2\|>Digits: Fixed\ I >Format : 

DISP 1;" Circle Properties": 

DISP 3 /"Radius n " R: 

DISP 4; "Circumference = " 2*\pi 
DISP 5; "Area = " \pi*R A 2: 
DISP 7; "Press any key...": 
FREEZE : 

Standards I > Format : ERASE 



Clear thr ftisjtiay 
Display the 

tit n! i ration- fof 
the tijifrf 



Prompt for the 
circle radius 

?B: 

Cfcur the display 

S& FIX.J<lisphn/ 

mode 

Display (he sen m 

title 

DLsptajf rnclt 

property 
f R: 



WaitJ&ra key 
press 

Rfsfnr* standard 
display format, 

clear thr display 



Programs ,PoIy2 through ,Poly4 do similar jobs. Each validates 
the value for R \ the radius), selects the appropriate equa- 
tions in the symbolic view, calculates die plot scale parame- 
ters, and sets the initial values for lire numeric view. Note 
diat the plot scale Ls calculated to 111 ah< m tfre meuir The 
menu occupies 1/8 the display, so an adjustment of 1/8 die 
calculated vertical range is made to the vertical scale. 
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PQlyZ (Side lengths) 
IF E\c=0 THEN 1\I>R 



CHECK 1: 

UKCHECR 2: 

DNCHECK 3: 

3\ I >X$nin: 

67 \ I >Xm*Lx: 

Fl(Xmax)\ I >Ym±ni 

Fl(Xmin)\ I *Ymax: 

Ymin- . 125* < Yroax- Ymin ) \ I >Ymin: 



3 \ I >NumStart : 



1\ I >Num£tep: 
Poly3 {Perimeter I 

IF R\< = THEN 1\I>K END: 

UNCHECK I* 

CHECK 2; 

UNCHECK 3 : 

3 \ I >Xmin : 

67 \ J >Xmax: 

F2(Xmin) \ I > Ymin: 

F2(Xmax)\ |>Ymax: 

Ymin- . 125* { Ymax-Ymin) \ I >Ymin: 

3\ I >NumStart: 

1\ ] >NimiStep: 

Pol^(Area) 

IF R\< = THEN 1\|>R END: 

UNCHECK 1 : 

UNCHECK 2: 

CHECK 3; 

3\ I >Xmin; 

67 N I >Xmax: 

F3 (Xmin) \ I >Ymin: 

F3 {Xmax) \ I >Ymax: 

Ymin- ,12 5* {Ymax-Ymin) \ I >Ymin: 

3\ I >NumStart : 

1\ 1 >NumStep: 

.PolyS (Polygon Properties} 



Ensure a mi> 
able valve for R 

Select equation Fl 






Fit the plot above 

Set the numeric 

to begin at 1 
and inc." ■ 
step* 



1 equation F2 



Select i guation FS 



INPUT X; "NUMBER OF SIDES" 

OF SIDES" ;X: 

ERASE: 

Standards | > Format : 



DISF 1; ' 



Sided Polygon" 



2\|>Digit8! Fixed\ I ^Format : 

DISP 3 ; "Approximating circle": 

DISP 4; "of radius " R: 

DISP 5;"Side lengths ■ Fl (X) : 

DISP 7; "Press any key*..": 

FREEZE: 

ERASE: 

Standards I >Format : 



DISP 1; J 



Sided Polygon" 



# SIDES"; "ENTER NUMBER 

Sides prompt 
t fear the display 
,s>7 standard 

forum! 

Bisplay ike screen 

title 

Set FEX 2 format 

Display circle 

nui> us uad pOly 

gon side length 

Wait for a kr</ 

press 

( 'fntf the display 

Set standard 

formal 

Display the semen 

title 



FixedV 1 >Format: 

DISP 3; "Polygon perimeter =" : 

DISP 4;" * F2(X) : 

DISP 5; "Circle circumference= 

DISP Si" " s*\pi*R: 

DISP 1; "Press any key.-.": 

FREEZE: 

ERASE: 

Standards I > Format : 

DISP 1 ; * ■ X " Sided Polygon" : 

FixedV I > Format : 

DISP 3; "Polygon are£- 

DISP 4;" " F3{X>i 

DISP 5 ; "Circle area=": 

DISP 6?" " \pi*R*2: 

DISP 7? "Press any key...": 

FREEZE : 

StandardM >Format : ERASE 



S^t FIX B format 
Display the 
perimeter and 

chvu inference 



Wait for a key 
press 

Clear the display 

trd 
formal 

title 

Set FIX 2 formal 

Display the area 



Wait for Q key 
press 

Restore standard 
display format, 
clear the display 



Building Your Own Aplets 

Your own aplcts can be as simple as the first example, 
somewhat more involved (like the Poly.Sides aplet), or very 
involved, with rnore complex user programs. Creating a new 
base aplet that can he downloaded into the HP 386 requires 
the use of System RPL prograniming beyond the built-in 
user program ming language. 

Basic Steps, The basic steps for building an aplet are: 

* Pick an appropriate built-in base aplel — Function, polar, 
parametric, etc 

• In each of l he views, enter the information thai applies. 
For instance, you would pin your equal ions in the symbolic 
view, pint parameters in the pl<>i setup view, and so on. 

* Pul a sketch Of the problem in the sketch view and a 
description of the problem in the note view. 

• For a fancier aplet, use SETVIEWS to attach user programs to 
the VIEWS key. Rememhei thai il may he handy to have a 

separate program that stores ihe setviews command while 
you Ye developing the aplet 

Row of Control* In general, the user of the aplet should deter- 
mine I lie How of control, so that a problem can lie explored 
freely. The PolySides aplet provides a little ex&& guidance 
by using the program Polyl attached to the start prompt in 
VIEWS. Polyl displays an initial screen, prompts for the circle 
radius, displays the circle's properties, and [amity exits io the 
note view as directed hy the SETVIEWS command hi general, 
i lie user should be able to navigate freely among the choices 
in VIEWS or the various views, or go home and come back. 

Shared Variables. The global variables A io Z. Z1 to ZQ, and so 

on an- imi stored within an aplel. so ii an aplel depends CHI 
ihe value of a global variable ii's a good idea to have the 
program associated with Start in VIEWS set these values. 
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HP PalmVue: A New Healthcare 
Information Product 



The HP PalmVue system integrates personal computer, alphanumeric 
paging, and palmtop computer technology into an effective solution for 
delivering timely and high-quality patient data to mobile physicians. 

by Edward H. Schmiihl, Allan P. Sherman, and Jon D. Waisnor 



The HP PalmVue .system (IIP M14JJ0A . j is a new offering 
from HP's Medical Products Group that allows transmission 
of clinical patient information to HP palmtop computers via 
conventional alphanumeric paging systems. This system 
integrates several forms of current technology, including 
computer networks, palmtop computers, paging systems, 
and devices to deliver a powerful new capability to hospitals 
and physicians who use IIP monitoring systems and cardio- 
graphs, This article will provide an overview of the operat ion 
of the PalmVue system and show how the system integrates 
several components to deliver this new service to clinical 
users. 

The User Need 

Us Saturday evening, and Dr. Ikeda is enjoying a rare dinner 
out with his spouse and another couple. As chief cardiok;- i^i 
of the Memorial Medical Center, he does not get much time 
to relax. This evening, he has largely been able to put our of 
Ms mind Ihe unstable condition of Frank Nielsen, a patient 
under his care in the Memorial cardiac care unit (CCU) who 
is recovering from a recent heart attack. Suddenly, the waiter 
taps him on Ihe shoulder and informs him of an important 
telephone call He goes to the phone, to be told by Laura in 
the CCU that Frank has developed a very irregular heart 
rhythm and she is very concerned about his condition. Since 
he at ways carries his portable computer and modem card, 
he suggests that Laura send him a fax of Prank s ECG so 
that he can assess the clinical situation himself. He goes to 
get his computer, and finds his way to a telephone jack that 
tile restaurant has allowed him to use. After several failed 
attempts, he finally gets the faxed ECG transmitted to his 
laptop computer. He is able to tell from the fax that Frank is 
in no immediate danger, but cannot read the ECG well 
enough to make a clear diagnosis. He tells Laura that lie will 
quickly finish his dinner and stop by the CCLr on his way 
home. 

It happens that Dr. Washington, another local cardiologist, is 
also out wit 1 1 his family celebrating a birthday at the same 
restaurant He has several patients in the CCU at St. Francis 
Hospital. As he is about to enjoy his appet izer. he hears the 
faniiliar sound of a paging aleii from ins pocket computer. 
He removes his HP palmtop compute]' from his pocket, waits 
a moment until the computer displays the HP PalmVue index 
screen, and presses a key to display the message. It is a mes- 
sage from Tony in the CCL\ Dr. Washington's cardiac patient 
H]ga Smetana has been having an increased number of pre- 
mature ventricular contractions (PVCs). and they seem to 
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turn to have changed shape. Tony s message says he needs to 
know if a change in dosage, or perhaps a new medication, is 
needed. Dr. Washington pushes another key and views Olgas 
ECG waveform in a crisp and detailed display on the palm- 
top screen. He can easily see that the PVCs are not really 
clinically different from those he has been seeing in Ulgas 
ECG for I he past few days. He pulls out his pocket-sized 
cellular phone, calls Tony in the unit and tells him that 
everything is OK with Olga, and he will cheek on her in the 
moming. He then proceeds to enjoy the rest of his dinner, 

HP PalmVue System Description 

The HP PalmVue system integrates personal computer, 
alphanumeric paging, and palmtop computer technology 
into an e f recti ve solution for delivering timely and Itigh- 
quality patient data to mobile physicians (see Ftg h i) r The 
dispatch station PC handles acquisition of the clinical pa- 
tient data. It also runs the user application to review arid 
select the data, converts the clinical data to paging mes- 
sages, and sends these messages to a commercial paging 
system through a modem connection. The HP PalmVue 
critical care system acquires patient data (such as patient 
waveforms and vital signs) from the HP Care Net monitoring 
network via the SDN interface card, For the HP PalmVue 
ECGstat application, the patients 12-lead electrocardio- 
graphic signals taken by an HP cardiograph are transit ted 
to the dispatch station PC via flexible disk. 

The paging messages travel through The paging system in 
exactly the same form as a typical "call me at SOI 457-8438" 
paging message, except that each message consists ©fa 
string of up to 230 meaningless characters. Most of the major 
paging providers [radio common carriers) send these pages 
from then paging system computers (known as switches) to 
a satellite uplink. The satellite retransmits the messages 
Through a downlink to ground-based paging transmitters in 
the geographical area covered by the subscriber's paging 
service arrangement This coverage territory may be a met- 
ropolitan area, a region, or an entire country. The transmit- 
ters broadcast the signals, which are then received by the 
pager. 

The paging receiver used in the HP PalmVue system is a 
device called a NewsCard. provided by Motorola This de- 
vice combines the radio circuits from a standard pager with 
processing, memory, and a PCMCIA (Personal Computer 
Memory Card International Association) interface, the indi- 
vidnal paging messages are transferred to the HP 200LX 
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Dispatch Station 
« Patient Selection 

* Data Review 

* Message Te*t Entry 

* Select recipient, 

* Initiate transmission to 
paging service provider. 

■ Connects up to 100 palmtop PCs 



Built-in Modem 




Transmitter 



Sends selected 
patient data to any 
medical palmtop 



Medical Palmtop Computer 

■ Transfers data from pager, 

■ D is p] ays patient data/notes. 



To Pager 
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1 1 < 1 1 1 . i < - 1 iputer by ;i software program developed by up 

for use in Hie IN' Si a r Link paging service, tithe Vws( 'i\ri\ is 

plugged into the palmtop when an III* PalmVue message 
arrives, tjte palmtop turns on aiid the messages are automat- 
icidly tmnsiem-'fl into die metttoft of the palmtop, If the 

• .-in I is m>i plugged trt, the messages are inii^hTivii 
\uU'\ aiter i hi' itsir plugs iii ihi> card and turns mi the palm- 
top. 

The hear! of the rIP Palm Vue system is the software, Tin- 
program in the dispatch station PG con3$>resses thecomplex 
patient data, transforms 11 into ;» series of short, character- 
based messages, and sends them i<» the paging service. The 
palmtop software processes the paging messages to recorv 
si tun thepatienl data, and bandies the user Interface and 
display oi thepatienl data on the palmtop screen. Refer to 
"fiat a Through Paging IfecJmoIog-y 1 ' oii page w for details of 
the packetizing and recpttstriiction process 



Hie HP PalmVue critica] care application provides a >nap- 
shctf rrf^hecurreni patieni data as acquired from the HP 
pattern monitor through the HTM aivNn. This data rnaa eoi* 
sisi of a I'-si i ujkI waveform snapshot [typically tin* BC6, 
used for assessing the patient's licari rhythm), up to fchrt 
(^second snapshots of other physiological waveforms (blood 
pressure waveforms or other measurements), and the hill set 
of vital signs (heart rate, blood pressures, He). the u&erat 

liie dispatch station selects the p< m data reviews!! on Hie 

PC screen, and freezes a particular snapshot of mimtuatinn 
for transmission m fche remote physician. The t*s£fr ran also 
enter a text no te to explain particular concerns or provide 
additional data io ilu* physician. After choosing the redpien] 
name, the user initiates the transmission ol the message. An 
unpte of the user screen on the dispatch station is shown 
EnRg,& 
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Unfreeze 

Transmission Progress 
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Fig. 2. An exantple ■ i to nse? 
screen on the dispatch station PC. 



The operation of the IIP PaimVue ECGslat application is veiy 
similar, except thai a previously acquired patient ECG is read 
in from a flexible disk (or ii may have been previously stored 
in ihe dispatch station PC), 

Operation of the palmtop application is designed to be as 
simple and intuitive as possible. If the NewsCard is plugged 
into the palmtop when a new HP PaimVue message arrives, 
the palmtop turns on, automatically transfers the paging 
messages into tire pal nil op, and executes the application 
program, This program reconstructs the patient data file and 
shows the index screen on the display with the new message 
highlighted (see Fig. 3). The user simply presses Enter, and 
the first screen of the new IIP PaimVue message appears on 
the palmtop display (see Fig, -1). Tills screen provides patient 
identification, the time the data was taken, and the text note 
as entered by Ihe sending clinician. Hie user ran access the 
clinical data portion of the message by using i lie function 
ki -vs. For examplej pressing ©Vitals brings up ihe patient's 
vital signs (see Fig. 5). The 15-seeond ECG waveforms can 
be accessed by pressing te Rhythm (see Fig. 6), Other portions 
of die pal lent data file, or alternate views such as expanded 
waveform time scales, are similarly accessed by using the 
function keys. Again, the palmtop application for display of 
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Fig, 3. Index screen an the palmtop display wit) i 1 1 Li j u -v. 1 1 j . ■ 



a patient's 12-lead ECG operates in a very similar fashion, 
with display formats tailored to useful presentation of the 
1 2-1 ead wav efo rnr air d d i agn ost i r i n f o r i n at i on . 

HP PaimVue Architecture 

Several key objectives drove the architectural design of the 
HP PahuVue system: 

Allow independent development aird testing of the dispatch 
station and palmtop portions of the HP PaimVue software. 
Allocate processing tasks appropriately to the dispatch 
station and the palmtop. 

Leverage existing software for - the critical care application. 
Isolate the transmission process as a subsystem to minimize 
regulatory concern about the specifics of the paging infra- 
structure. 

Develop the key software modules in lire P( and palmtop ro 
be independent of the paging technology to allow a smooth 
transition to alternate wireless communication technologies. 

Hie resulting architecture provides a good Solution thai 
meets these goals and allowed for a smooth development 
process. 
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The IIP PaimVue system architecture is shown in Fig. 7, The 
key ID achieving many of the design objectives is the clinical 
message fi I e. This file is a specially defined representation 
of the clinicaJ patient data, together with appropriate identi- 
fication and control information. It exist.-* in the system as a 
standard DOS binary file. This allows the clinical message 
files to be created, edited, and transported using conventional 
PC tools. The clinical message file is provided as input to 
the transmission process within the dispatch station PC, and 
is reconstructed within the palmtop software. 

This design greatly facilitates testing. Each application sub- 
system can be tested and verified independently by either 
evaluating the clinical message file as output from the PC, or 
by providing a valid ciinica I new ssage file as input to the 
palmtop, The entire software system can be tested without 
any use of the wireless communication subsystem. 

This design also resulted in optimized system performance. 
The bulk of the processing load, which is the transformation 
of waveforms into scaled display data, is handled in true dis- 
patch station PCS. The scaled waveform data that the palm- 
top receives in the clinical message file requires kit little 
processing to display on the palmtop screen. 

The inclusion of explicit error codes in the clinical message 
file allows the verilir;itinn Of data inlvmlty with total inde- 
pendenre I'min the Urn amission subsystem. This allowed 




Fig. 6- -ing 

V fifty* 

the regulatory concerns for data integrity to be addressed 
without consideration of the specific performance charac- 
teristics of the paging systems. Both the clinical message 
ill* -based architecture and the error code implementation 
are capable of transparent migration to other wireless (or 
wireline i communication methods. 

Background of the Product Concept 

The availability of Palmtop computers, along with compat- 
ible paging devices and services, created the potential for 
wireless transmission of patient data to tht*se tiny computers, 
The early product concept included the original Palmtop 
(the HP 95LX), and a paging device called the NewsStream, 
which connected to The serial port of the Palmtop using a 
cradle. The HP 95LX display allowed only coarse waveform 
presentation, and the combination of Hie Palmtop, cradle, 
and NewsStream was somewhat unwieldy. However, proto- 
typing based on these concepts, using the 12-lead ECG, 
showed the feasibility of the product idea. 

Dr. David Albert, a technology oriented physician with pre- 
vious ties to the IIP Diagnostic Cardiology Division, became 
a champion for commercialization of the product. Having 
formed a company (Data t t ii iml ( '* >rporation, or DCC) to 
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Data Through Paging Technology 



The Data Through Paging software, which is licensed to HP by Data 
Critical Corporation, allows patient information in the form of a binary 
file (the clinical message file) to be transmitted through a conventional 
alphanumeric paging system and received on a palmtop computer 
equipped with a NewsCard paging receiver 

Transmission Data Structure 

Two types of pages are generated and transmitted by the dispatch station 
applicatteii The first type is the file identification packet This page is 
sent redundancy as the first and last packets. It identifies the clinical 
message file and provides the clinical callback phone number and the 
name of the institution This page is sent as readable text and is dis- 
played when the clinical message is not received successfully. 

The second type of page is the clinical message packet The clinical 
message file is divided into clinical message packets using the process- 
ing step outlined below. The clinical message packets can be transmitted 
redundantly if that feature is selected in the dispatch station application. 

Clinical Message File Compression 

The clinical message file is compressed using a lossless compression 

algorithm. The approach, which is based on industry- standard concepts 
and algorithms, is referred to as LVSS, The algorithm employs dictionary- 
based and Huffman encoding processes This combined algorithm is 
similar to the commercially available LHARC program and the widely 
used PKZIP The compression is intended to decrease the number of 
pages sent through the paging service provider by about 50%. As part of 
the compression process, a 16-bit CRC error detection code is computed 
and included with the compressed clinical message file. The CRC serves 
both to check the integrity of the compression process and to detect 
errors that might have been introduced by the transmission process.. 

Encoding 

the compressed clinical message file, whrch is in the form of 8-bit binary 
data, is translated into 7-bit printable ASCII characters. The bioary-to- 
ASCH encoding step is necessary to use the paging system, which was 
originally intended for the transmission of only printable ASCII charac- 
ters, The algorithm is similar to the uuencode utility used with many 
UNIX'- 1 emait programs. This process tends to introduce an overhead of 
30% in the clinical message file size, This encoding overhead is more 
than offset by the gams obtained through compression. 

Packetization 

The encoded clinical message file is divided Into small blocks of ASCII 
characters. The size of a block is dictated by the maximum page length 
allowed by the specific paging service used. Each block contains header 



information for later identification of the data block, which allows correct 
reconstruction of the clinical message file after reception in the palmtop. 
The header contains a clinical message file filename, a block sequence 
number, the total number of blacks in the clinical message file, and error 
detection codes. Each block is then packaged into a page with Te locator 
Access Protocol (TAP) control characters embedded in preparation for 
sending to the paging service by modem. Each page also contains infor- 
mation that is used later in the RF transmission stage to target specific 
receiving pagers. 

Data Transmission 

A telephone line connection is established between the dispatch statiun 
modem and the central paging switch modem. TAP is used to upload the 
packetized clinical message file to the paging switch. TAP establishes 
communication handshaking,, performs forward-acting error correction 
using checksum calculation, and retransmits erroneous packets when 
requested The uploaded pages are then RF-transmitted to the target 
pager device (or devices) by the central paging system The order of trans- 
mission of the packets is not necessarily the same as the order of recep- 
tion by the paging switch. 

Receiving Pages 

On the receiving end of the RF link, the process is reversed to recreate 
the original clinical message file. All pages in a clinical message file are 
stored by the NewsCard paging receiver rn its local memory, where they 
can be downloaded into the receiving palmtop computer The relevant 
clinical message file pages are then redirected to a temporary incoming 
clinical message file page file based on the header information supplied 
with each page. The last page sent contains a coded message that acti- 
vates a palmtop macro to start processing 

Clinical Message File Reconstruction 

The HP PalmVue application accesses the incoming clinical message 
file page file and, using the page header information, reorders and 
reassembles the received pages. The reassembled page message is then 
translated from 7-bit ASCII to 8-bit binary data to reverse the pretrans- 
mission encoding process The decoded clinical message file page file is 
then decompressed to reconstruct the original clinical message file, which 
is then stored It is displayed by the palmtop application only if the CRC 
sent with the clinical message fife matches the CRC computed by the 
palmtop. 

UNIX rs a registered trademark in me United Slates and other countries, licensed exclusivity 
through X/Qpen Company Limited 

X/Open is a registered trademark and the X device is a trademark of X/Open Company Limited 
■ snrj alter countries. 



pursue building products based on this technology; he 
searched for partners to provide an -ess to sources uf clini- 
cal patient information as well as established market ing 
channels, He found an enthusiastic sponsor in Jim Cyrier, 
the division manager of I IPs patient monitoring business, 
-Tun had a well-developed vision of the future needs of medi- 
cal professionals for access to patient data whenever and 
\\ herevei [fc, so he saw great promise in this product 

Concept. Jim set in motion a process that resulted in a con- 
tract between HP and Dt\ Alberts company for the joint 
development arid marketing of die PalmVue system. 



Underlying this product are two major concepts, One is the 
usefulness of providing complex patient data lo physicians 
on a pocket-sized device, winch is enabled by the advent of 
the IIP palmtop, a tiny computer with a high- resolution 
graphics display. The other is the ability (seen by many in 
the paging industry as "not possible") to send huge, binary 
information files through I he standard and ubiquitous alpha- 
numeric paging s ys tem s. Refer to "Data Through Paging 
Technology* above for the details i if i he data compression, 
translation, packet izing and reconstruction process used to 
implement thi> capability. 
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Product Development 

The product definition for HP PalmVue was a joint effort of 
the engineering teams front the HP Patient Monitoring and 
Diagnostic Cardiology Divisions, working together with Data 
i rit ical Corporation. The prunar j$ *als were to pro- 

vide liigh quality and useful displays of patient data on the 
palmtop computer, to provide a very simple and intuitive user 
interface for the palmtop user, and to ensure the integrity of 
any patient data presented to the physician, The patient moni- 
toring team developed a prototype of the palmtop displa 
using Visual BASIC on a PC, These display screens were 
transferred to the palmtop, where wded detailed 

screen formats and basic user interface controls* This proved 
to he a very effective method for quickly developing detailed 
prototype screen formats and control structures for evalua- 
tion by the development team and representative clinical 
users 

The development of the HI 1 PalmVue critical care and K( r .- 
stat applications followed separate paths The critical can- 
product built on existing software products to provide a 
framework for the dispatch station application and a proven 
subsystem to acquire patient data from the HP CareNet 
patient monitoring network. The PC application to provide 
the HP PalmVue user interface was developed by the engi- 
neeriiig team in the IIP European Project Engineering Center 
by leveraging their DocVue product. Data Critical Corpora- 
i ti >n. under the development provisions of the contract, de- 
veloped the transmission software for the dispatch station 
PC and the data reeonsti \u ii< >u and user application soft- 
ware for the palmtop. Tlie program management, system 
integration, testing, and product documentation Wf&e per- 
formed by the project team at the HP Patienl Monitoring 
Division. 

The development path for the HP PalmVue ECGstajl produd 
was Ear simpler. The HP Diagnostic Cardiology Division de- 
veloped the initial produd specification and Data Critical 
Corporation developed all of the PC and palmtop software. 
Substantia] portions of the software (other than the PC user 
application) are common between the two products 

Thejmnr development plan Cor these products made optima) 
use of the strengths of the partners. The IIP patient monitor- 
iru and cardiology groups have substantial knowledge of 
their reflective clinical application areaa Tfn-> also have 
highly refined and hum.ih/ed processes for product defini- 
tion, architectura] design, regulator} approval, and softwan 
uuaHtv assurance In the ease of the critical care, prodia i 
existing produd software from tin- IIP European Projed 



Engineering Center was also a key HP contribution- Data 
Critical Corporation provided their established Data Through 
Paging technology, current knowledge of paging - and 

paging devices, and specific expertise in programming in the 
system manager environment of the HP 200LX palmtop. 
Substantial learning occurred by all of the partners Data 

ration was forced to conform k* the rigorous 
testing and software QA methods required by HP\ regular 
and ISO 9001 processes, while HP embraced the 
rapid product creation and aggressive attitudes that are the 
strengths of a small startup company 

:mis needed to adapt quickly to evolving tech- 
nology as die project progressed. While the early prototype 
was based on the HP 95LX. the HP 100LX was introduced 
during the early stages of the development work. B;- 
time of product r< HP 200LX was announced and 

became the platform for the initial HP PalmVue products. 
The paging device evolved from the bulky NevvsStream to 
the PCMCIA-based NewsCard. The advent of the NewsCani 
provides the end user with a compact receiver setup that 
Call he ivadily carried in a pocket or purse. A team in HP 

< < >rvallis and IIP Singapore was concurrently developing 
interface software for ih*- NewsCard, and they modified 
their software product to make HP PalmVue possil 
Adapting to these changes required the development and 
lesA teams to be flexible and efficiently rework their soft- 
ware and test procedures to accommodate the evolving HP 
PalmVue product configuration. 
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Constructing An Application Server 

In a dynamic networked environment in which there are several hundred 
workstations and servers there is a constant demand for new versions of 
software, In this environment software installation procedures must be 
quick, flexible, and tolerant of change. 

by Jill E. Swenson 



With the rapid advancements and constant changes associ- 
ated with computer technology, new and better hardware 
arid software capabilities can always be expected. Hardware 
conies and goes as needs fluctuate, and software popularity 
tends to bloom and lade as fast as software features evolve. 
All this change makes managing software installation and 
updates across nu tog than $00 I NIX" systems a very chal- 
lenging task, This paper describes a project to simplify s< >n 
ware administration among a inoup of workstal ions ai HP's 
Integrated Circuits Business Di vision. 

At one time our division software was purchased by system 
owners and installed on individual workstations as requested 

Users shared common applications by connecting their work- 
stations in HP-UX 1 clusters in which one machine's disks 
were nsed by many diskless workstations (cnodesK 1 These 
clusters grew large, and access 1 < i m ifi ware became a more 
important component in deciding system confignrat inn ihan 
performance or networking issues. Some software was 
sharer I between cluster servers through NFS mounts, and 
(his led to what we call ^spaghetti mounts," which is many 
machines mounting portions of each others* disks to access 
shared software | Ki& 1), Additionally, software installations 



were no* t racked, software versions were not synchronized, 
and network licensing was not effectively implemented. 

My goal for this project was to find a way to reduce users* 
dependencies on cluster configurations, to untangle the 
mounts, and to improve the way we installed, updated, 
removed, and tracked software. To do this, I moved the 
application code files to a central server and connected all 
the user workstations to tins server (see Fig. 2). Pile servers 
are not an unusual concept, but application servers create 
unique challenges, and this one needed to be as easy to use 
as possible. 

Developing the Structure 

Since we had some spare equipment and" disk space, a central 
software server was a convenient choice for the application 
server. The basic concept was in place — add disks to the 
application server, install software on those disks, mount 
those disks to cheat machines, and enable the client ma- 
chines in run the software. Two issues that had to be deal I 
With were how to mount disks so it mi symbolic links would 
be followed correctly on the application server and on the 
clients, and how to isolate each application and allow it to 



Standalone 
System 



User Application B 




SoftWindows 



User Application A 



NFS (Remote} Mounts User) to Gain 
Access to Software Applications on 
Remote Systems 

Local Disks 



Fig. l. A: i example of "spaghetti 
mounts,* 1 winch is nmny machines 
mounting portions of earii others' 
disks to access snared software. 



70 June 1D96 Hewlptt-Pac karri Journal 



)Copr. 1949-1998 Hewlett-Packard Co. 




NFS 'Remote. Mounts Used lo Gain 
Access to Software Applications art 
Remote Systems 

Local Disks 
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reside in its desired location on each system, Finally, since 
saving administrative effort was equally important, the 
entire process needed to be automated, 

A search of the literature produced a helpful article describ- 
ing how 10 manage local software on a tun work.- Even more 
conveniently the article included (he authors installation 
script. Although not entirely suitable for our environment, 
this article provided valuable ideas for establishing moiutt 
points, isolating applications, and creating configuration 
files for each application. 

Mount Points 

To identify mount points, I looked at documentation for the 
HP-internal I 'MX ( ormrion < >pcrating Environment 
COE) and the HP-VX LO.O operating system. Both doc& 
ments recommended using different locutions fot mounting 
local and remote ( NFS-mot i tiled) disks. This meant that disks 
physically connected lu the application server would he 
mounted in one location on the server (e.g., /mnt/diskli and in 
a different location on the servers clients (e.g., /nfs/servername 1 
ctrskl ) (see Fig. 3l This approach makes logical sense, but it 
is limited because there is a route n> a file oil the server thai 
the client doesn't know about. In Other won Is. the server 
could refer to a file l>\ the name/mnt/diskl/filename, but that 
name would not be valid on a client. The client must call 
ilia I Hie /nfs/servername/diskl /filename. 
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Why Is this a problem? 

Calling a file by multiple names typically does not cause 
problems. However, most application installation programs 
have a problem wilh multiple names because i|ie\ arl under 
the assumption that code is insialled on the machine where 
it w ill be used arid not. on an application server. Many instal- 
lation programs detect the directory into which code Is 
installed and then plug that directory name into scripts, use 
it to create symbolic links, and so on. The resulting scripts 
and links work correctly on the application server, hut fail 
on clieni systems, 

h i handle this, disks were mounted in the recommended 
locations and symbolic links were created on the application 
server to all* m it to refer fcO its owti disks under the nann is 
used by Ihe clients. Thus, when software is Installed it is 
always redirected, if possible, to the name used l>y clients. 

In retrospect, this was not the best solution. Some particu- 
larly difficult Installation processes resolve all symbolic 
links to their absolute paths and use these paths lo create 
scripts and symbolic links. Tims, no matter what name was 
used for ihe installation directory, 1 would find some refer- 
ence In/mnt/diskl I ticked away in a software configu ration 
li]< or script. Ihe only way to tool these programs is to 
either ignore recommended standards and mount the disks 
to /nfs/servername/diskl on both the client and the server, or 
create "fake" symbolic links to the mount, points on both 
machines, 

After considering both options, I determined thai the fust 
option had the least number Of disadvantages and was (tie 
simplest to impfemenl 

Software Organization 

The next question was how lo organize (he software on the 
shared disks < (pinions varied. One- approach was to pin all 
code into a common bin din Ctorj and sel it up so that the 
administrator Owned the tun director} on all inaehines. 
Altlumgh this would ensure consistency, ir wasn't verj 
flexible. Since all users don't have identical software needs 
i : some may he testing a new version of soli ware while 
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others niiglu be installing software packages that are not 
shared with others), il did not make sense to force all sys- 
tems h> liave an identical bin directory, 

The approach used in reference 2 suggested isolating each 
application in its own directory tree and organizing the eonv 
portents of the application in explicit directories (documen- 
tation files under the doc subdirectory, binaries under bin, 
etc.). This idea of isolation was good, but il required spend- 
ing time unnecessarily reorganizing the eodfe components. 

The software packages we were dealing with came from 
multiple developers, each of whom had a different idea about 
where an applications files should reside and the relative 
location of different components stteh as library, binary, and 
configuration files. There was some n mcei il I hat many of 
these software packages would not react well to being moved 
around or being forced to run out of an unexpected directory. 
The best approach was to install each application into a 
separate directory on the shared disks, and to use symbolic 
links to allow the application's files to be logically located 
wherever they would normally expect to be in si ailed. 

To keep this neat, each software package is installed Into its 
own directory as if that directory were the root directory on 
the system. In other words, if an application called editor 
came wiili a file called editor-diet, which it expected to reside 
in /usr/lDcal/lib f a directory for the new' application would be 
created: 

/ nf s / servername/ di ski / editor 
and the editor, dictionary) file would be installed in 

/nfs/servername/diskl/editor/iisr/local/irb 
/editor. diet 

When this software is finally hooked up to client systems, 
they will each have a symbolic link: 

/usr/ local /lib/editor .diet -> 

/nfs/ Bervername/di ski /editor /usr/ local / 1 ib 

/editor .diet 

The software can find its data file where it expects, and all 
the files associated with the editor program can be isolated in 
one directory tree which can be easily removed, replaced, or 
modified as needed. 

Each applications directory tree mimics the root file system, 
making it easy to see where the software components will 
ulliruately reside on client systems. Developers like the de- 
sign because they can easily see the relative relationship of 
all their files in isolation. 

There are two significant issues with this approach. First, it 
requires thai a large number of symbolic links be maintained 
on multiple systems. Second, some applications might require 
configuration changes on the client or insist that certain 
fiks physically reside on 1 h e c 1 i e a 1 1 s hard dis k . 

The solution to both of these problems is a configuration file 
and a process (script) to use il. 

Configuration File 

Every application on the application server has an associated 
configuration file. This is an ASCII file, created manually, 
that contains all the instructions necessary for installing the 



application on a client For most appli cations , the configura- 
tion file simply lists a number of symbolic links to create, hi 
die example above, one Line in the editor program's configu- 
ration file would look like: 

LINK: /nfs/servername/diskl /editor /usr/ local /lib 
/editor. diet : /usr/local/lib/editor .diet 

Each line in the configuration file contains a tag field fo] 
lowed by several < ul< ni-scpamted parameters. The tag field 
is a word that has meaning to the configuration script In 
ibis example, the LINK tag lells the script to create a sym- 
bolic link using the next two fields as arguments. The syntax 
for the LINK command is: 

LINK: /link/to/directoryi /I ink /from/ directory 

Additional tags cause the configuration script to copy files 
(COPY), unlink directories (UNLINK), or execute programs. 

Creating a configuration file is the most time-consuming 
action required when installing an application. It requires a 
good knowiedge of the directory smicinre on client machines 
and an understanding of the runt ime environment expected 
by the application. The overall goal is to minimize the number 
of links wdiile allowing multiple appJieal tons to be installed 
where they wish. However, with a little creativity nearly any 
application can be dealt with, and once the configuration file 
is constructed, it remains unchanged and can be used on 
every client 

The configuration file is also used to un install software. An 
option on the configuration script causes it to deal with cer- 
tain commands in reverse, removing links and files that had 
been copied to the client. 

In accordance with HP-UX 10.0 file structure recommenda- 
tions, the configuration file is created in /etc/opt/a ppname/c on - 
fig.fs. To make the configuration files readable from client 
machines, they are placed under each applications directory 
tree. Thus, the /nfs/servername/diskl/editor/etc/opVeditor/conffg.fs 
file would be the configuration file for the editor application 
mentioned above, 

The Script 

The configuration script is nsed to install an application 
located on a file server on a workstation (i + e> t it sets up links 
to applications on the server). Because the configuration 
(and application) files reside on a remote server, a new client 
must mount the remote server's disks before installing soft- 
ware The installation script establishes mounts (m option) 
to the file server and creates the required links f-c opt ion ) 
using in formation from the configuration file. The installa- 
tion script has an option (u) to undo a mount and uninstaH 
software. The command line to the configuration script to 
establish the mount points and set np the links for the editor 
application w T ould be: 

scriptname -m servername : /mnt/diskl: /nfs/ 
servernanie/diskl -f-c /nf B/eervernane/ 
di sk 1 /editor /etc/ opt /edi tor /conf ig.f e 

The -m option introduces the server and client involved in 
establishing the mount points, and the -f and-c options intro- 
duce the configuratitiri file. 
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The configuration script is written in Perl (Practical Extrac- 
tion Report Language) because this is rlu- language that pro- 
vides th> :u< -U -jit techniques for reading 
through t _ nation file once* storing the information, 
and acting on it later. Shell scripts require more coding to 
perform the same steps, and a C program would have to 
compiled for every platform we support. Thus, Perl was a 
good choice. Fig, 4 shows the portions of the installation 
script responsible for mounting disks and reading a configu- 
ration file. 

The configuration script reads and acts on instructions in 
die configuration file. It checks the first field of each line for 
a tag, which is a special word (e.g., LINK) describing a com- 
mand Unknown tags are ignored. 

Because .nation files reside on the server, clients 

nmsi mi mm the server's disk before attempting to read any 
configuration files. Although the configuration script can be 
used to mount the servers disk, it does not currently modify 
a client's hoot procedures or its /etc/checklist file. The system 
administrator still needs to perform these steps manually. 

The configuration script uses the same configuration file for 
installing and iirmist ailing. It does an uninstall by removing 
all files or directories listed as LINK or COPY in the configura- 
tion file. 

Remaining Issues 

With any project there are always lingering issues. This sec- 
tion describes some of these Issues, 

Software Location and Fine-Tuning. Although it's convent en I to 
1 1 h air software centrally not everything belongs on a remote 
machine. Ideally enough software should remain on local 
workstations so that the umts are reasonably functional 
wtien the application server is down for maintenance. This 
means that key files such as operating system components, 
screen icons, and critical applications such as electronic 
mail readers should reside on local systems. Also, perfor- 
mance is impacted by accessing remote files so finding the 
right mix of local and remote riles can have a significant role 
in application performance. 

Software Installation Programs and Headaches. Most installation 
programs expect the code to he installed on the machine 
In >n i which it is run and don't embrace the concept of reim >te 
access. Good installation programs allow you to change die 
default installation location and log every step they take 
and the friendliest programs place all files under a user- 
specified location. Bad installation programs silently tread 
in certain system areas by adding user accounts, modifying 
boot scripts, and changing the system Configuration, Bypass- 
ing installation programs, tracking dow fl all the changes 
they made, and rewriting processes to duplicate the installa- 
tion on client machines is Ihc most time-consuming part of 
installing new software 



Read-only Environment ideally, the application server's disks 
should be mounted read-only Unfortunately, some applica- 
tions require write access to shared files, so we use read- 
write NFS mounts. However, application directory permis- 
sions are kept tight so that users are not able to write to the 
server 

File Ownership Conflicts. I Occasionally, two different applica- 
tion i . will both try to "own" the same file. I first 
encountered this with two Lotus*" applications I was install- 
ing: AmiPro/I X and Lotus Notes/UX Both vc: me 

rrt/latug/bin/lpconfig file and the files were hot identical. 
Normally, the version a client receives depends on the order 
in which the two software packages are installed. If AmiPro 
is installed last, a client will run AmiPros version of the 
Ipconfig file. If Lotus Notes is installed last, the client w ill run 
the Notes version. 

Inconsistency and Supportability. To ensure that all users, no 
matter which software package was installed, used the same 
application versions, some rearranging was necessary. 1 in- 
stalled the Lotus applications mentioned above on the appli- 
cation server into their' own separate directories. Next, I 
copied all duplicate files to a third directory, using the ver- 
sion of the files that came with AmiPro- Finally I modified 
the configuration files for both Ami Pro and Lotus Notes so 
that clients would link to these duplicate files in the common 
directory. 

This fix allowed the complete AmiPro and Lotus Notes prod- 
ucts to be installed and available, if a problem arises with 
any of the common files, it s easy to change the file in one 
place and make sure the fix reaches everyone. 

Summary 

PStflj the application installation process has been a great 
success. Users are running consistent vorsi< ms of applica- 
tions, sharing centrally managed licenses, and no longer 
choosing to be part of a cluster simply because of the soft- 
ware available on that cluster. Application providers are 
able to make modifications in one local ion accessed by 
everyone The application server contains no ttser accounts, 
runs very few processes, and is a fairly well-behaved I/O- 
dedicated machine. Unlike a cluster, (be seiver can suffer 
occasional downtime without bringing down client systems, 

We still run clusters, and the application server works in 
that environment as well. But the clusters are smaller and 

they are bring implemented for the right reasons— not 
because of application availability. Many users are choosing 
standalone workstations, where they are allowed greater 
flexibility to install experimental versions of code or to use 
as much swap and disk space as they like without impacting 
Other users 
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# Options : # 

# -m Mount info: Revive /establish mount points # 

# -c Configfile: Revive/establish links tt 

# -f: Force symlinks and mounts (removes # 

# existing files and directories) * # 

# -u : Unmount or remove links , depending # 

# on other options used # 

# -v: Verbose # 

# # 
require ' getopt s , pi J ; 

do Getopts ( 'm; c : fuv' ) ? (K) 

# Initialize variables 
$numlinks^O; 
$numunlinks-0; 



################################################ 
ft Read mount information. # 

################################################ 
sub readmount { 

print "Starting readmount subroutine \n" 

if ($opt_v); 



Jelse 
{ 

exit 97; 
} 
} # End subroutine makemounts 

ft#ft#ft#########M##M#ftft##ft###########ftftftft####### 
ft Read oonfig file* filling up variables with # 
ft contents, # 

sub readconfig { 

print "Starting readconfig subroutine \n" 

if t$opt_v)? 

while ($_=<CONFIGFILE>){ ("g'; 

# The configuration file consists of an initial 

# tag and colon-separated parameters. Break each 
ft line into its components 

chop; 
($tag, @parms)=split {/: /) 



# The mount parameter consists of the machine 
ft to mount from, the directory on that machine 

# to mount and the directory to mount to {on 
ft the client machine)! all separated by ":" 

ft characters* 

ft Break line into its components. 

® ® 

($machine / $mountf roiru $mountto) -split 

( / : / t $mountpoint ) i 



} ft End subroutine readmount 

## ########f############ft#########ftft##ftftftft##ftft##ft 

# Perform mounts, creating directories, if # 

# needed * # 
#ftft#ft######ftftft##t#######ft################ftftft##ft# 
sub makemounts { 

$dontdo=0 

if (substrfSmountto, 0, l)eq '/') 
{ 

print "Making" . $mountto . "Vn"; 
if [ (system("/usr/bin/bdf $mountto I /bin/ 
grep $machine s $mount f ram" ) )==0) 

{ 

print "Correct mount point already exists\n"; 

$dontdo=l; 

} 
ftmakedir i"$ffloiintto") ; E 
print "mounting $machinei $mountfrom\n"; 
if ( ( -d Smountto ) && M Sdontdo J ) 

{ 

system ("/etc /mount -o soft $machine: 

$mountfrom $mountto"); (f) 

} 



if (Stag eq "LINK") I 'H 

$ 1 inkto [ $ numl inks J = $parms [ J j 

$ 1 inkf rom [ $numl i nk s ] = $parms [ 1 ] ; (l) 

$numl inks + + ; 

} 



}# while 
} ft End of subroutine readconfig 

########ft###ft###ftftftftft##ftftftft#ftft################## 

# Process links; Create all links specified in # 

# config file (must run readconfigO first). # 
##########################ftftftftft#ft############### 
sub linkall ( 

print "Starting linkall subroutine \n" 
if ($opt v) ; 

for ($i=0; $i< ($numlinks ) ; $i + +) 
{ 

$linkf rompath=$linkf rom[$i] ,- 
Slinkfrompath= s* [a-z,.0-9.\-]*S"i 
# Chop file/dir name off path 

ft If parent directory path doesn't exist , 

ft create it. 

fcmakedir ( "$linkf rompath" ) ; 

ft Check for existing file/link (exit or 

# remove it depending on -f option) 
if (-e $linkfrom[$i]£&( ! $opt_f ) ] 

C 
print "Non-Link exists;' 1 , $linkf rom[$i] . 
"TerminatingVn" ; 



Fig. 4 . Pe rr loua of rhe configiini I " ■ r ig disks, miding configurat in 1 1 ! ■ - and I Teat iiig links. 
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exit 9B: 

> 

elsif <-e $linkfrom[$i3 )tfc($opt_£) J 
{ 
# Force t-f) section - force the link {remove 
P exisiing : . : . 1 1 G 3 " : E y tX&G 
if f-f $linkf rom[$l] ) 
< 
print "Forcing removal of File" 

:from[$i] . "\n"; 
unlink ( $linkf rom[$i] ; 
) 
elsif <-d $linkfromf$i 
{ 

print "Forcing removal of directory" 
, $linkf rom[$i] . "\n"j 
system ("/bin/nn -rf $linkf romfSi] ** ) ; 



} 
for ($i=Q; $.i< (Snumlinka) ; $i++) 
i 
Bymlink ($linkto[$i] , $linkfrom[$iJ 7 (If) 

print "Linking from " . $linkf rom[$i] . 
"to " ,$linkto[$i] . "\n"; 
} 
> 






® 
® 



Input Siring 

-m servername : /mnt / diskl : / n£ s / servername / 
disks -f -c /nf s/ servername /disks /editor/ 
etc/opt/editor/config. f s 

Server's Name 

Server s Name for Disfcl mnt /disk 

Clients Mount Point nfs /servername /diskl 

Make Directory /nfs /servername /diskl 

Mourn nf s/ servername /disk 1 to mnt /diskl 

conf ig. sys 

Teg = UNK 

/nf s/ servername /diskl /editor /usr/ local/ 
lib/editor, diet 

/usr / local /lib /edit or .diet 

Create Symbolic Link: 

/uar/local/lib/editor . diet — > nfs/ 
servername / di ski / editor /usr / local / lib/ 
editor .diet 



Fig. 4. (Continued) 
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Interface Translation for Reuse of 
Assembly-Language Modules in a 
TWo-Language Environment 

A mixture of low-level and high-level implementation languages is likely 
when old modules are reused. In a two-language system, some interfaces 
must be expressed in both languages. This paper describes the design and 
implementation of a production-quality software tool that solves this 
problem for the C programming language. 

by James R. Buffenbarger 



The advantages of developing a software system in a high- 
level programming language rather (han a low-level assembly 
language are well-known. Nevertheless, many embedded 
systems have been and continue to be developed in a low- 
level language. This implementation language paradox is typi- 
cally jusri fled in terms of the required execution efficiency 
or the lack of high-level software development tools. 

r lVpieally, a new system is but J I from a mixture of old and 
new modules. The old modules are often from a previous 
system. Depending on. their age, they may be implemented 
in a low-level language. The new modules might be imple- 
mented in a low-level or high-level language. 

This paper is concerned with the development and reuse of 
intermodule interfaces in a system requiring a mixture of 
low-level and high-level implementation languages. Such a 
mixture is likely when old modules are reused. New modules 
might also be implemented in a low-level language, but they 
are more likely to be implemenled in a high-level language, 
since processors are getting faster, memories are getting 
larger, and high-level software- development tools are 
becoming available. 

hi this paper, a problem is identified and defined , several 
possible approaches are proposed, and the most promising 
approach is selected and pursued. The design and imple- 
mentation of a production-quality software tool that solves 
the problem for the C programming language are deserib* id 
in detail and short-term industrial experiences with this fool 
are briefly described. 

The Problem and Possible Solutions 

Suppose a two-language sysiem contains a module named f. 
Clearly, f should have only one implementation. However, 
f may need two equivalent interfaces; one for each language. 
There are several possible approaches: 
Manually develop and maintain a low-level Interface only. 
Tliis approach requires f and every user of its interface to be 
implemented in I lie low-level language However, f or one of 
its users may be a new module, which suggests a high-level 
implementation. 



• Manually develop and maim aiu a high-level interface only. 
This approach requires f and every user of its interface to be 
Implemented in the high-level language. However, I or one 
of its users may be an old low-level module, which should 
be reused raihei than reimplenienhd 

• Manually develop and maintain both interfaces. This 
approach allows f to be implemented in either language. 
However, the probability of inconsistency is very high, as 
it is tor any instance of double maintenance, 

• Develop and maintain the high -level interface manually and 
derive the low -level interface automatically, according to a 
well-defined transformation. This approach also allows Ftp 
be implemented in either language, but avoids double main- 
tenance. Note | hat the reverse transformation is not possible. 

Interface Translation 

The last of these approaches seems to be the most reason- 
able, and is pursued here. Interface translation Ls flexible, 
accurate, and fast, 

In many languages, mi interface is contained in what is 
called an include file. Tims, deriving a low -level interface 
from a high-level interface means translating an include file 
written in a high -level language into an include file written 
in a low -level language- An include-file translator can be 
used in at least t wo ways* 

Suppose a programmer is writing a module named g and 
needs to use a module named f. If the programmer is an 
assembly-language programmer, module f needs lo consist 
of an assembly-language include file fine* which specifies the 
interface off, and a binary object file f.Dbj for linking. On the 
other hand, if the g programmer is a C-language progranuuer, 
module F needs to consist of a C include file f.h, which speci- 
fies the interface oft and a binary object file f.obj for linking. 
Therefore, the "user view" of module f is the three files: f.Inc, 
f.h. and f.obj. These three files must be available so that both 
assembly-language and C-language programmers can use 
module f. 
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shown her*. 

flies on the left i aii trained manually. 

Module f may be written either in assembly language or in C. 
If it is written in assembly- language, there will be an assem- 
bly-language file la96 which implements the interface off 
ami includes fine. Iff is written in C, there will be a C file f.c 
which implements the interface ofi and includes f.h. 

Therefore, if f is written in assembly language, the following 
files are necessary so that both assembly-language and C 
programmers can use module f: f h, fa 96, f.inc. and f.obj. With 
an include-file translator, only fin and f.e36 need to be main- 
tained manually; fine can be translated from f.h, and f.obj is 
assembled From fa 96, The processes are shown in Fig. 1. 

If f is written in <_'. the following files are necessary: f.h, f.c, 
f.inc, and f.obj, Again, with an include-file translator, only f.h 
and F.c need to be maintained manually; One can be trans- 
lated from f.h, and fob) is compiled From f.c. The processes 
an* illustrated in Fig, 2, 

Include-file translation is similar to compilation. In fact, one 
way of interpreting these ideas is as additional requirements 
for a compiler. Perhaps emnpiler /assembler vendors wUl 

eventually incorporate these features into their products. 

The ideas presented here are programming language inde 
pendent However, for demonstration purposes, a particular 
assembly language and a particular high-level language ('(') 
are discussed. Furthermore, just one implementation of 
what should be considered a class of translation tOOlsis 
described 

Pre l ranslator Environment 

We begin with a description of an environment that needs an 
include-file t ranslator. 

Tin software is developed in an evolutionary way. in a heter* 
ogeneotts i-nvirnnment. The software is large and mature, 
residing in an centralized version-controlled repository, 
The development platfrmns are workstations based on the 
I NIX". MS-DOS"; and « S2 operating systems The ttn'tjrt 
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Fig. 2. Foi .i module f, written m <'. to be usable hv both assembly- 
1 1 i n-: 1 -,!! nil' r- -m Foui EHes hown here .n- needed 
with an te traiislator, only the files on the leil need 

maintained manually. 



platform is an embedded system based on an Intel micro- 
controller. The software is developed in assembly language 
because good cross-compilers for the target plat Form do not 
e.vlst, compiler-generated code is too slow, and compiler- 
generated code is loo big. 

e software developers and their man. ?_ 
lyfora change. New m i croc onr rollers are much fa>r 
an d t hey can address m M anage r nent 

rt-i - agnizes the potenti i] ■ ■ i >Jer and processor 

independence, not the least of which is die freedom to buy 
development tools (e,g M emulators) from more than one 
vendor. Good cross-compilers are finally available. Ww 
developers would become productive more quickly if the. 
did not have to learn an esoteric assembly language, All 
developers would become more productive if they could 
program in a high-level language when appropn 

In ?his environment, the high-level language of choice is (\ 
but its complete and immediate adoption has well-founded 
resistance, For speed and Space, efficiency, some parts of the 
software should never be rewritten in t\ Furthermore, those 
parts of I he software that should be rewritten in C repn 
an enormous corporate investment. An effort to rewrite all 
of them at once would have severe short-term productivity 
and quality costs. Instead, the unanimous understanding is 
that only some of the assembly-language modules should be 
replaced by C modules, and then only in a prioritized piece- 
meal fashion. Thus, the environment must .support two- 
language devc lopm en l . 

A Tool for Two-Language Development 

consider the consequences uf rewriting an assembly- 
language module named J in C. The original module has two 
parts: an assembly-language file named t.inc, specifying the 
module's interface, and an assembly- language file named 
f.aSfi, implementing the module's interface. 

Likewise. tin- new module has two parts: a ( EOe named f.h, 
specifying the module's interface, and a I file named frc, 
implementing I he module's interface 

However, other assembly language modules still need the 
nobly -language interface fcof. That is, they need l<> in- 
clude fine in one way or am >i her. I >ne solution is in maintain 
both f.h and fine manually This solution is tedious and error- 
prone, A better solution is to maintain f.h manually and auto 
matieally translate it inlo fine with a lool. Such a tool needs 
to be able to translate I he subs, i of G thai OCCUTS in a h File 
in t o assenib ly langu agi ' . 

Two brief definitions are relevant. A target assembteF is a 
cross-assembler from a development plai Form lo the target 
platform Analogously, a target mmiiilcr\s a C eross-eompiler 
from a development platform to (he larget platform. Note 
thai the word size of the compiler with which the translatoa 
is developed typically differs From thai or a target assembler/ 
compiler pair 

The eharacterislics of C are Fairly standardized, stable, and 
well-known; those of assembly language are uol. Thus, I he 
translator needs In be rHargt (able, primarily For different 

target assemblerv^compHer pairs, several aspects of a partic- 
ular target assembler/compiler pair are described below, not 
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because they are interesting in themselves, but because they 
provide insight into the translation task and help explain the 
example presented later. 

The target assembler has several relevant characteristic \s. 
It uses a preprocessor, similar to a C preprocessor, Lo e fieri 
file inclusion, macro definition, and conditional inclusion. 
It processes rwu kinds of Mfjuato directive, EQU and SET, whose 
difference is irrelevant, here. It processes EXTRN directives, 
which are analogous to C extern declarations. Symbols and 
values have types such as: NUtt, BYTE. WORD, POINTER, and 
ENTRV. During assembly, the output for each statement goes 
to one of several segments that are available (eg., code, 
data, stack, or register). 

The target compiler has only one relevant characteristic. 
Its algorithm for detennining the distance from the begin- 
ning of a struct to a member requires alignment analysis of 
the types of all members of the struct. 



Prior Inclusion 
Preprocessing 



Deli ue Direchve 
Pre processing 



C Preprocessiny 



Scanning and Parsing 



Include-File Translation versus Compilation 

Although the translator is much Like a C-subset compiler, 
there are significant differences. For example, the translator 
generates code from a fdefine directive, but a compiler does 
not. On the other hand, a compiler generates code from 
statements included by a include directive, bul the translator 
does not. 

A more interesting difference concerns error handling. 
A compiler can stop producing output (Le. t object code) as 
soon as it detects any non warning error. In contrast , the 
translator must recover from most errors, including syntax 
errors, and produce as much correct output ("i.e., assembly 
code) as it can. In many cases, translation errors are quite 
acceptable, representing declarations that are simply 
inaccessible to assembly-language programmers. 

Translation Details 

The indude-file translator accepts as input a subset of the C 
programming language. This subset consists of C modules 
(also known as translation units 1 ) that do not define func- 
tions or variables. Such modules are conventionally stored 
in include files, with a h file name extension. Accordingly, 
the translator need not recognize the following reserved 
words: auto do return break else static case for switch continue 
goto while default if However, the translator does understand 
the reserved words near and far as qualifiers for pointer 
types, 

Like a conventional compiler, 2 the translators operation can 
he understood as a sequence of phases (see Fig. 3): 
L I Yi o e i n c I u s i on p rep r oeessing 

2. Define directive preprocessing 

3. C preprocessing 

4. Scanning and parsing 

5. Code generation. 

As usual, phases 4 and 5 are interleaved. The phases are 
described below, 

Prior-Inclusion Preprocessor. An include file can reference an 
identifier declared in another include file, but the former 
does not. necessarily include the latter. The prior-inclusion 
preprocessor solves this problem. 



Code Generation 



Fig. 3, liidude-ttle translator operation consists of t\ series of ph 



For example, suppose f.c contains the following: 



#include 
#include 



,h" 



and fh references an identifier from ah. To translate fh, a.h 
must be processed first. However, declarations from ah 
must not produce output . 

The prior-inclusion preprocessor solves the problem by eon 
struciing a file containing #inc I ude directives, #line directives, 
and the content of the original input file (i.e., fh). Later 
phases only produce output for declarations from the origi- 
nal input file. 

The prior-inclusion preprocessor is implemented with Awk. 3 

Define Directive Preprocessor, In general, a ^define directive in 
the input produces output. However, G preprocessors delete 
^define directives. The define directive preprocessor solves 
this problem. 

For example, suppose the following line is line five in file fh. 

#define SIZE 100 /* size of something */ 

The define directive preprocessor translates 1 bis into the 
following lines. 

#define SIZE 100 
#line 5 "f,h" 

%%% "SIZE" %%% SIZE %%% 

Since normal C preprocessing lias not yel been performed, 
the original #define directive must be retained. 

The #l«ne direciive allows error messages from subsequent 
phases to accurately specify the location of an error. Here, 
subsequent phases must recognize that a line has been 
inserted during preprocessing. 

The three-character token %%% is effectively a new reserved 
word, G preprocessing ignores all but the fourth token on 
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this line, which it replaces with the definition of SIZE in the 

usual way. Phases after C preprocessing recognize this state- 
ment and produce output from it corresponding to the origi- 
nal #define directive. 

Initially, an @ was used rather than %%% but some I 
cessors complained about it. The probability of a programmer 
accidentia using three adjacent modulus operators seems 
inw The identifier is used as the fourth token, rather than its 
definition, to ensure correct operator precedence during 
evaluation in later phases. If the identifier has no definition, 
a 1 the fourth token. The line ends with %%% to 

prevent the parser from skipping loo many tokens during 
error recovery. 

The define directive preprocessor is also implemented with 
Awk. 

C Preprocessor. This preprocessor is an ordinary i ! prepro- 
cessor (e.g. T eppj, The translator expects the value of an 
environment variable to specify a particular preprocessor. 

Scanner/Parser. This pari of the translator is essentially a 
front end for a normal G compiler. Several differences are: 

* Only the subset of C described previously needs to be 
recognized. 

* The new %%% statements are recognized. 

■ The definition part of a %%% statement is evaluated. Since it 
can be any C constant integer expression, its evaluation is 
not trivial. Furthermore, evaluation is simulated to occur 
according to the word size of the target compiler, which 
may be different from the word size of the translator and 
simulated arithmetic overflow is detected and reported 
The alternative to evaluating the expression (luring transla- 
tion is to translate it into an eqtdvalenl assembly-language 
expression, 

* Most errors, including syntax errors, do not preclude code 

generation. 

Tin- scanner/parser is Implemented with Yacc, * Lax, 6 and 
GPerf/' 

Code Generator. Since the translator only translates declara- 
tions, this part is simpler than the back end of a normal C 
compiler Its primary task is to output assembly-language 
directives and declarations, based on the content of atypi- 
cal symbol table, which is built by Lhc scanner and parser. 

To simplify retargeting, target compiler lyjn sizes ;md type 
alignment rules are encoded iii a tabular Fashion. Likewise, 
target assembler mnemonics and r>pe names are easily 
modifiable. < lode ts generated only for declarations from the 

original input tile. Declarations limit hies it includes produce 
no output 

Translation Algorithm 

The translation from V 10 assembly language is predomi- 
rumlly syntax-directed, In other words, each syntactic eon- 
n ui i in tin- C subset Is translated to a line of assembly lan- 
guage. Ilowt-ver, as in a normal compiler, the symbol table 

provides coiileM The iranslated c onslnicts are described in 

the following paragraphs* 

Define Directives. A Adeline directive, without arguments and 
whose replacement text is a const aui integer expression, is 
translated to a SET directive. The value is that of the expivs- 
ston* which is evaluated according to the word size of the 



target compiler. Simulated arithmetic overflow is detected 
and reported. For example. 

tdefine TWO 1+1 
is translated to: 
TWO SET 2:NDLL 

r kinds of #define directives are not translated. 

Enumeration Members. An enum declaration dec lares at least 
owe member. Each such member is translated to an £QU 
directive. The value is that which would be assigned to the 
member by the target compiler For example, 



e num numb e r s 


t 


zero. 




one, 




two. 




ten=5*2 


i 


eleven, 




twelve 




); 




is translated to: 




zero EQU 


OiNULIi 


one EQU 


iiNULL 


two EQU 


2: NULL 


ten EQU 


10: NULL 


eleven EQU 


11 t NULL 


twelve EQU 


12 i NULL 



Structure and Union Members, A struct or union declaration also 
deelai - es at feast one member. Again, each such member is 
translated to an EQU directive, The value is the offset, in 
bytes, from the beginning of the nearest enclosing Structure 
hi union, according to the target compiler. For example, 



struct STH { 




doub! 


Le d; 




doub! 


Le *dp; 




int i 






char 


c, *cp, b; 


}; 


float 


. f; 


is translated to: 


d 


EQU 


:NULL 


dp 


EQU 


4:NTJLL 


i 


EQU 


8: NULL 


c 


EQU 


10 : NULL 


cp 


EQU 


12 r NULL 


b 


EQU 


16: NULL 


f 


EQU 


18: NULL 



\oii( filial alignment ore urs. A command lini' nptiun 
causes Structure and union member names to heijualified 
by the nearest enclosing structure or union tag (e.g., i ii* * 
translation of the second member would equate ft*e identifier 
STRJptofour). 

Nested structure and union declarations force an interesting 
decision. A member's oflsei can be computed as tin* distance 
from the beginning of its ( 1 1 nearest enclosing structure or 
union or r Jj outermost structure or union. Both offsets ;nc 
valuable to an assembly language programmer Both of&etfi 
require name mialifieanoii In differentiate idem iral member 
names to distinri structures or unions, However, offset '1 
requires a i|i ml i Ileal ion for each tevel of nesting, which can 
quickly exhaust the3l-characterlen^h limit fori identifiers. 
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In addition, offset 1 allows a programmer T< > *-« impute \ >ffset 
2, as necessary, Therefore, offset 1 is considered the best 
choice. 

Structure and Union Tags. In addition to its members, a struct 
or union declaration optionally declares a tag> Such a tag is 
translated to an EuU. The value is the size in bytes of the 
structure or union, according to the target compiler, For 
example, for the previous sin it hire. The translation is: 



extern Car *car; 

extern Car FixCarfCar ear), 



STR 



EQU 



22: NULL 



Variable Declarations. A variable declaration (i.e., a variable 
definition prefixed by extern) is Inmslated To an EXTRN direc- 
tive. For example, 



extern 


int 


a[10] ; 


extern 


int 


fcj 


is translated To 




EXTRN 


a 


: POINTER 


EXTRN 


e 


;WORD 



These directives are ouipui in data segment space. If the (' 
reserved word register is present, they are output in register 
segment space, 

Function Declarations, A function declaration (i.e., a prolo- 
lypr) is also translated h> an EXTRN directive, PVir example, 

extern int ft int x, int y); 

is translated to: 

EXTRN f : ENTRY 

These directives are output in code segment space. 

An Example 

This section provides a concrete demonstration of the 
include-file trmslal or described in earlier sections. Relevant 
aspects of the translator's interface are presented and an 
example translation is shown. 

The translator recognizes a variety of command-line argu- 
ments and environment variables, but nuisi of them arc not 
very interesting. Hie important command-line arguments 
are: 

i specifies the input file 
-o specifies the output file 
-q simulates prior inclusion of a include \,. M file 
1 -a simulates prior inclusion of a include <. > file 

The only important environment variable is cppcmd, which 
allows any preprocessor to be used, rather ihan the 
default. Thus, the translator can be executed as folic us s 

c2as -i ears.h -o cars, inc 

Suppose cars h contains the following code: 

idefine MAKELEN 9 

#define CARS 3 

typedef enum {black=10, red, blue) Color; 

typedef char Make [MAKELEN] ; 

typedef double Price; 

typedef struct Car { 

Color color; 

Make make; 

Price price; 

struct Car *oldcars [CARS-1 J ; 
} Car; 



Then, after translation, csrsJnc would contain the following 
Intel i960 assembly-language code. 



MAKE L EN 


SET 


9:MTJLL 


CARS 


SET 


3: NULL 


black 


EQU 


10 j NULL 


red 


EQU 


11: NULL 


blue 


EQU 


12: NULL 


Car_color 


EQU 


0:NULL 


Car_make 


EQU 


2 : NULL 


Car_price 


EQU 


12: NULL 


Car oldcars 


EQU 


16: NULL 


Car 


EQU 
DSEG 


20:NULL 




EXTRN 


car: POINTER 




CSEG 






EXTRN 


FixCar: ENTRY 



Integration with Build Process 

From a build-process perspective, an include-file translator 
is no different than a compiler: it translates a source file 
into an intermediate form. Like a compiler, the translator's 
invocation should be automated by a build process. There 
are several details, which are described below, A build pro* 
cess based on Make 7 is assumed. 

In general, only some of a system's V include files need to be 
translated. These .h files need to be identified. Topically, a 
Make variable is used for this purjKt.se. 

A single rule is sufficient to tell Make how to translate any of 
the previously identified .h files into a corresponding .inc 
assembly- language file. Some versions of Make can use static 
pattern ruff's for this, while others can use dynamic prereq- 
uisite macros to accomplish the same thing. If these Make 
teal un's are unavailable, multiple rules are required. 

Any additional dependencies of each resulting .inc file must 
be specified explicitly, in two ways. First, Make must be told 
about the dependencies, but this can be done with ordinary 
rules. Second, such a dependency may require a mmsl;m>r 
option specifying prior-inclusion preprocessing, as described 
above. This second kind of dependency cannot be computed 
automatically. Fortunately, an esoteric Make feature called 
f ■ f j u if ml <•<! V f n vVi hfc h ( n ti rs can eu s I o mize translat or optic ns 
for different ,h files. Again, if these Make features are unavail- 
able, multiple rules are required. 

Conclusion 

Include-file translation supports the reuse of modules whose 
interfaces must be expressed In both a high-level language 1 
and an assembly language. These two-view interfaces allow 
a module to be implemented in either language and refer- 
enced by other modules implemented in cither language. 
The basic approach is to maintain the high-level interface 
manually and automatically derive the low-level interface. 

The C include-file translator described above has receni l\ 
been implemented and incorporated into the software build 
process used by a group of about 2U Unaware engineers m 
f h'uleil-F'aekards Disk Memory Division, the translator was 
implemented for the UNIX and MS-DOS operating sy si ems 
by one person working half time for about six months. The 
firmware upon which the translator operates consists of 
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code. She also worked as a software engineer on the 
HP 48SX scientific calculator for which she designed 
and implemented plot and graphics code and worked 
on the HP Equation Writer She is professionally inter- 
ested in the use of technology in education and has 
coauthared two papers on the HP 48G/GX and HP 
48 SX calculators Diana was born in Portland. Oregon 
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honors in 1982 from Portland State University. She 
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tion I rotary card for the HP 
48SX. Currently an R&D engineer in the Asia Pacific 
Personal Computer Division, he is responsible for the 
design of the nexi -general ion handheld calculators 
and information appliances Recently he worked on 
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science m 1984 and a PhD in 
computer engineering in 1987, both from Nanjing 
University at Nanjing. He became a lecturer at Nam 
jing University doing teaching and research, then 
moved to Singapore to work on computer-aided 
Embroidery pattern design software. He joined HP's 
Asia Pacific Personal Computer Division in 1993. As 
an Rao engineer, he worked on the design and im- 
plementation of the HP 3BG calculator, including the 
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59 Creating HP 38G Aplet 5 

James A. Donnelly 

1 iphy appears elsewhere in this section 




a* 



64 HP PalmVue 



Edward H. Schmuhl 

tftam Division) He >s work* 

iver medic-:: is via 

: years at HP Ted has held 

various positions within product developmw 
mg software engineer, project leader, and manager 

Some of his contributions have been trie development 
of the architecture and software • IP's first 

microprocessor-controlled patient monitor, manage- 
ment of the design and integration of HP's Care Net 
pa tiem monitoring network, and project management 
of the HP PalmVue project. Bef- '-' he 

worked at RCA Corporation developing automated 
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shoal 275 files occupying over 13 megabytes, About c»te 

rjgarfer of these files contain C source code, while ihe r*st 
contain assembly -language source code. The translator is 
used on about 3Q include files. 

For the most pari, the experiences and comments of those 

involved have been positive. Surprisingly, arithmetic -over- 
flow checking caused problems, because fJie target assem- 
blers word size depends on ! lie complexity of an expression 
(u|M-rator-free expressions can be large), In addition* several 
users requested an out pui -file preamble of comments. These 
comments contain file names, version numbers, and time 
stamps. 

The vast majority of difficulties have been with build pro- 
cess integration rather than translation. I sers have had 
trouble understanding and correctly using the prior-inclusion 
preprocessor. Typically, a flic containing a typed ef is omitted, 
which causes the parser to produce a parse error message. 
In addition, a .inc files dependence on its corresponding h 
file is not properly recognized by the mechanism responsible 
I r automatically checking out the .h file from die version 
control system. 
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